################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally published in the Proceedings of the USENIX Summer 1993 Technical Conference Cincinnati, Ohio June 21-25, 1993 For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org X Through the Firewall, and Other Application Relays G. Win#eld Treese MIT Laboratory for Computer Science and Digital Equipment Corporation Alec Wolman University of Washington and Digital Equipment Corporation Abstract Organizations often impose an administrative security policy when they co nnect to other organiza tions on a public network such as the Internet. Many applications have thei r own notions of security, or they simply rely on the security of the underlying protocols. Using the X Window System as a case study, we describe some techniques for building application-speci#c #r elays# that allow the use of applications across organizational boundaries. In particular, we focus o n analyzing administrative and application-speci#c security policies to construct solutions that satis *fy the security requirements while providing the necessary functions of the applications. 1 Introduction This paper presents some general techniques for making network applications a* *vailable through secure gate- ways, based on experience from managing an Internet gateway at Digital Equipmen* *t Corporation's Cambridge Research Laboratory (CRL). Like many organizations, Digital operates #rewalls a* *t its Internet gateways to isolate the internal network from the rest of the Internet. This isolation is only part* *ial, because communication is the goal of the connection in the #rst place. Unfortunately, the Internet is not al* *ways a safe place, and some form of protection is necessary. A #rewall (sometimes called a #gateway#), such as those described by Cheswick* * [2], Ranum [11], or Schauer and Wolfhugel [13], is a collection of computers intended to protect an organiz* *ation connected to a public network. The fundamental premise in the design of #rewalls is that it is easier to secur* *e a small number of systems rather than hundreds or thousands. A #rewall isolates insecure systems inside the orga* *nization from the public network. We discuss the design of traditional #rewalls in more detail below. At CRL, we began with a traditional #rewall system. CRL operates one of Digit* *al's connections to the Internet, and the #rewall has been in place since that connection was established. At the* * outset, each person who needed access to the Internet also needed an account on a trusted #rewall system. The * *only exceptions to this rule were those users who only needed to use electronic mail and USENET news, which were * *forwarded appropriately by a trusted gateway operated as part of the #rewall system. Assigning user accounts* * does not scale very well, however; the administrative costs alone can be prohibitive. Because of this, only a smal* *l number of people were allowed to have accounts. In order to provide some limited Internet access to more people, we began imp* *lementing #relays# for various applications, such as FTP, Telnet, and X. A #relay# is an intermediary program,* * speci#c to a given application, that permits users on the inside of the #rewall to use services available on the pub* *lic network. The relays run on trusted #rewall systems. Thedesignofapplicationrelaysisnotmerelyatechnicalproblem. Anorganizationmayha* *vean#administrative security policy# that makes some statements about what is allowed and what is n* *ot. Relays must respect these policies. The challenge is designing a relay that both provides the needed appl* *ication functions and satis#es the requirements of the security policy. In this paper, we discuss some general principles for attacking the problem o* *f designing relays to satisfy both technical and policy requirements. We use our experience with constructing a re* *lay for the X Window System [14] Figure 1: Typical Firewall Con#guration as a case study. After some brief de#nitions, we begin with discussions of traditional #rewall* * design and administrative security policies. Next we describe our approach to building the relay for X. This is fo* *llowed by short descriptions of some other example applications. We compare this approach to some others from the re* *search community and conclude with an evaluation of our experiences and some discussion of possible future wo* *rk. 2 De#nitions In the sections that follow, an #internal# network is one inside an organizat* *ion connected to the Internet, and an #external# network is the Internet. Note that #secure# as used here means some * *reasonable level of security, not an absolute high level. The goal of our work has been to extend services without s* *acri#cing a signi#cant portion of the security that already exists, whatever that might be for a given applicatio* *n. We use the term #router# to refer to a device that operates on packets at the* * network layer. A #gateway# operates at the application layer (which may encompass the OSI [18] session, presentatio* *n, and application layers). 3 Traditional Firewall Design Atypical#rewallcon#gurationmayconsistofseveralcomputersystems. Theseincludero* *utersusedtoseparate the internal and external networks as well as secure hosts that may be used for* * interactive use. A diagram of a typical #rewall con#guration is shown in Figure 1. The routers used in the #rewall are often capable of #screening# packets to s* *elect desired ones and discard undesired ones. Screening routers can be used to permit direct access between i* *nternal machines and external ones. One screening router implementation for UNIX systems is described by Mogu* *l [7] (although not all of these have the #exibility of the one Mogul describes). Similar capabilities are* * now available in many commercial routers. Such systems allow a system manager to select packets based on some co* *mbination of protocol, source and destination IP address, and source and destination port numbers. Some uses of screening routers include: fflProtecting #rewall systems. Even though a system is part of the #rewall, w* *e may wish to prevent it from exchanging certain kinds of packets with external machines. For example, a * *dedicated mail relay may not need to allow telnet access from external machines. Putting it behind the s* *creening router adds an extra layer of protection. fflLimiting interaction between #rewall systems and internal systems. A #rewa* *ll system probably does not need full access to all internal systems; its access should be limited to t* *he functions that are required. Such a restriction limits the possible actions of an intruder who compromises th* *e #rewall system. fflAllowing widespread access for certain services. There may be a few servic* *es that are deemed suf#ciently safe for all internal systems to use. Such services may include, for exampl* *e, the FTP and WHOIS services operated by the Network Information Center (NIC). If we believe that the NI* *C is unlikely to be compromised, then there is little risk posed by allowing such access. Screening routers can provide substantial protection, but there are many appl* *ications that are dif#cult to support using only screening routers. To circumvent this problem, #rewall con#gurations* * often include a few privileged hosts that have broader access to the Internet (although their access may not b* *e complete). Rather than allowing directcommunicationbetweeninternalandexternalmachinesforapplicationssuchaselect* *ronicmailandUSENET news, the privileged machines accept mail or news messages and deliver them app* *ropriately on the other side of the #rewall. An application such as remote login requires a different solution * *# rather than allowing remote logins between all internal and external machines, a typical con#guration would requir* *e all users to login to the privileged machine as an intermediate step. These user accounts add some administrative ov* *erhead to managing the gateway. This overhead is an important factor in how large the gateway can grow. Firewall con#gurations of this nature are currently available from several ve* *ndors and consulting services. 4 Administrative Policies Most organizations connected to the Internet have some sort of policy concern* *ed with the security aspects of the connection. In many cases, common to universities, the policy is that no* * security should be assumed. Other organizations, such as companies or government agencies, frequently have * *detailed policies that limit use of the network. We will refer to such policies as #administrative policies.# So* *me examples of issues covered by administrative policies include: fflWho can use the connection. Typically only employees or those individuals * *otherwise associated with the organization may use the connection. Many organizations further limit the s* *et to those who have authorized user accounts on certain computers associated with the connection. fflWhat kind of data #ow can occur. Many organizations are concerned about po* *tential #ow of private information outside the organization (for example, the source code to a cri* *tical product). Others are concerned with the #ow of data into the organization (for example, employee* *s retrieving proprietary data from another company). fflWhich applications can be used. Policies frequently limit the set of appli* *cations that can be used with a connection. These limits may be based on lack of a demonstrated need for th* *e application, a belief that the application is unsafe (whether because of known problems, a guess, or a his* *tory of security problems), or expected violations of other aspects of security policy. For example, an ou* *tgoing #le transfer utility may violate the policies surrounding the kinds of data #ow that are permitted. Tothetechnically-orientedreader,suchpolicies(orvariationsonthem)mayseemsilly,* *excessive,orineffective. In some cases, they are. In other cases, the issues may be more subtle. For exa* *mple, information can #ow out of a company in many ways, especially in the hands of a disgruntled employee, so r* *estricting outbound data transfer may not seem reasonable. On the other hand, consider a thief who breaks into a * *corporate computers system using a 1200 baud modem. He cannot download a large quantity of source code quickly o* *ver such a connection, but he might be able to take advantage of a high-speed network connection to move the * *code out to some other machine on the network. In this case, restrictions on data transfer serves to limit the* * damage the thief can cause. In any case, we are not concerned here with de#ning or defending particular c* *hoices of administrative policies. Given a policy, we want to analyze it in the contexts of particular application* *s in order to construct an appropriate gateway. These policies are not stated in a formal fashion; part of the problem* * is constructing a real system that satis#es a vague policy statement (and its issuers). 4.1Example Administrative Policy For our case study, we consider the following policy: fflAccess is limited to those with authorized user accounts. fflUnauthorized individuals must not be allowed to gain access to internal ma* *chines or information. fflIt must not be possible for individuals to transfer large amounts of infor* *mation out of the organization at high speed. Individuals with authorized user accounts are trusted not to ab* *use their privilege to send out proprietary information. fflThe gateway machines should keep reasonable logs about their use. Like most administrative policies, these policies are general statements and * *do not prescribe speci#c details for implementation. Often it is important to understand the intent of the polic* *y as well as its statement in order to construct a system that satis#es the makers of the policy. The policy descri* *bed above, for example, may be understood to permit electronic mail, even though mail allows some outbound tra* *nsfer of information. Mail is usually not high bandwidth, and some information about each message is usually * *logged. In Section 7 we describe some other applications and variations of the admini* *strative security policy. 4.2Scope of Protection In this paper we are primarily concerned with protecting applications. We do * *not address issues such as spying on individual packets on the Internet, the abuse of protocols to create covert * *channels for signaling, forging source or destination IP addresses, or #hijacking# a TCP connection by inserting packe* *ts with proper sequence numbers into the connection. Many of these potential problems with TCP/IP are discussed* * by Bellovin [1]. Although we do not consider them here, these potential problems should be considered when d* *esigning a real #rewall system. 5 A Relay for the X Window System Some applications are dif#cult to operate securely with traditional #rewall c* *on#gurations. In our case, the critical ones were applications using the X Window System. After implementing a* * solution to the X problem, we began to investigate other applications where we could apply some of the same g* *eneral techniques. In the X Window System, the basic security model allows a user to control the* * set of hosts allowed to make connections to the X server. This control only affects new connections, not exi* *sting ones. Many users disable the access control entirely for personal convenience when using a more than a few h* *osts. Researchers at CRL often collaborate with researchers at universities, and th* *ey want to run applications on the university machines with the X display on a workstation at CRL. Because of X's * *weak security model, simply allowing all X traf#c to pass through the screening routers would not meet our * *security requirements. Since we had no technical way of enforcing the use of access controls, we had* * to assume that the internal users would not use the existing access control mechanism carefully. There are also h* *ooks in the X protocol for passing other authentication data to the server; we explain below why that mechanism is* * not suf#cient. One approach might be to modify the screening routers as necessary to allow c* *onnections between speci#c machines. The main problem with this approach is the management overhead. To ke* *ep the screen up to date would require a system manager to take action whenever a new connection was needed or* * when an old one was no longer necessary. A privileged application to do this would require substantial access* * controls and authorization for the users. For quite some time, if a researcher asked for this capability, the answer wa* *s that it was simply unavailable. Fortunately, researchers don't like to take #no# for an answer, especially when* * it has to do with getting their work Figure 2: Dialog box for xforward done, so we began thinking about how to provide this capability. We realized th* *at we needed to solve the following problems: fflLimiting which systems could connect to an internal display. Since the add* *ress of the client host is the best information we have about the client, we can use it to restrict which hosts* * can connect. fflEnsuring that there were no unauthorized connections. Limiting connections* * to a small set of systems does not eliminate all problems. A hostile user on an allowed system might try t* *o connect to the display. The X protocol allows a client to spy on the entire state of the screen as well a* *s the input stream, so a client can silently eavesdrop on other applications. fflNot modifying any client or X server software. Since we have no control ov* *er either the clients or the servers, we could not require any modi#cations to the software. This ruled out modif* *ying clients and servers to use a strong authentication system such as Kerberos [16] or SPX [17]. The #rst problem means that we are limited at best to a solution based on IP * *addresses, not authenticated individuals. That immediately led us to the second problem, of ensuring that no* * unauthorized connections were made by other users of the remote machines. Our solution is a modi#ed TCP protocol forwarder called xforward, which is ru* *n by a user on a privileged gateway machine. A TCP forwarder is a program that listens for data on a port a* *nd forwards anything it receives to another system. The screening router is con#gured to only allow X traf#c bet* *ween the internal hosts and the privileged gateway. xforward allows the user to specify a list of hosts that ar* *e allowed to connect to the X server. It establishes a relay between a pseudo-display number on the gateway machine a* *nd the user's workstation. Foreign X clients attempt to establish connections to the pseudo-display on t* *he gateway machine, where the list of allowed hosts is checked. When that check is successful, the connection must* * then be explicitly approved by the user through a dialog box created by xforward. The dialog box is shown in Figur* *e 2. This makes the establishment of each connection an intrusive action and ensures that the user is aware of al* *l connections created to the display from the outside, so an intruder cannot spy on the X server. In addition, the l* *ist of allowed hosts is speci#ed at relay startup time, and there is no way to disable this mechanism or to specify* * wildcards. If there is no activity on any connection for a certain period of time, all connections are closed and the* * relay terminates. For reference, the xforward manual page is shown in Appendix A. This solution may seem rather simple. Indeed, it is not a matter of deep thou* *ght. The interesting principle here, however, is that we can use speci#c knowledge about an application to create a * *relay that provides the required functions of the application while preserving a desired security policy. In the* * next section, we describe several examples in which the application semantics differ enough that xforward itself * *would not work, but the general principle of analysis applies. 6 Example Applications Other applications that we have used in this way include FTP, Telnet, WHOIS, * *and sup (a software distribution program developed by the Mach project at Carnegie Mellon). In each case, we use* *d a similar process of analyzing the application's security policies and the administrative policies to develop * *a relay that provided the necessary functions while meeting the administrative policies. For comparison, the sectio* *n concludes with analyses of electronic mail and USENET news in the same framework. 6.1FTP The File Transfer Protocol (FTP) [10] is widely used on the Internet for copy* *ing #les. We may wish to allow many people on internal systems to copy #les to and from external systems. With* * the policies we are currently considering,thatisnotpossiblewithoutgivingeveryoneanauthorizeduseraccountongate* *waymachines. Suppose, however, that we relax the administrative policy slightly: fflAny employee can copy #les from systems on the Internet to internal machin* *es. This rule does not differ much from the general intent of our original exampl* *e. It does, however, give us some additional freedom to implement a gateway mechanism. There are two challenges h* *ere: one a technical problem and one caused by the administrative policy. The technical challenge is that FT* *P uses separate control and data connections, so a simple TCP relay is insuf#cient. The administrative challenge* * is that this policy does not permit copying #les from internal machines to external machines, so even a simple FTP * *relay that can manage the data and control connections is not suf#cient. The solution in this case is an FTP relay that checks each FTP command before* * passing it through. Requests to store #les are denied, and other requests are passed through. In addition, o* *f course, the FTP relay limits access to internal machines. Such a relay has been implemented; a sample interaction w* *ith it is shown in Figure 3. Given an FTP relay, however, we may be able to expand the offered service wit* *h an additional relaxation of the policy: fflAn employee may transfer #les out if the identity of the employee can be d* *etermined and recorded. Authorized user accounts satisfy this requirement. We can also satisfy the re* *quirement by using a strong authentication system, such as Kerberos [16], SPX [17], or #smart cards.# In fa* *ct, a system has been implemented based on the the SecureNet SNK-004 from Digital Pathways, Inc. An individual wi* *th a registered key is allowed to transfer #les after authentication. Figure 4 gives a sample dialog with this* * service. Hence, with an understanding of both the administrative policy requirements a* *nd the details of the FTP implementation, we can devise a functional relay. If we understood the policy a* *nd had only a vague understanding of how FTP works, we might conclude that such a relay is not possible. If, on t* *he other hand, we understood the FTP implementation and did not fully understand the policy, we might conclude t* *hat such a relay is not permissible. 6.2Telnet Telnet [9] is widely used on the Internet for remote logins. General telnet a* *ccess between internal and external machines can serve many purposes, supporting cooperative work projects* *, customer support, and traveling employees who need to read their electronic mail. The relaxed version of the po* *licy described for FTP is suf#cient to permit a telnet relay implementation using a simple TCP relay and dialog to * *set up the connection, given some kind of strong authentication mechanism. With #outbound# telnet (from an internal machine to an external one) we can t* *ake an extra precaution, however. In the abstract, we are supporting interactive remote terminal service, not arb* *itrary data connections. Hence, it may be reasonable to limit the data rate on the outbound connection to (say) 96* *00 bits per second. This is surely fast enough to handle a person typing; we are not interested in anything more. 6.3WHOIS WHOIS [6] is a TCP-based query/response service, often used as a directory se* *rvice. The Internet Network InformationCenter(NIC)hashistoricallymaintainedanamelookupserviceforindividuals* *ontheInternet(although the Internet is now so large as to make maintaining a centralized directory imp* *ossible). % ftp ftp-gw Connected to ftp-gw. 220-FTP passthrough server 220-To connect to a remote FTP server give your login as: 220-user@server.serverdomain (EG: anonymous@host.cs.mumble.edu) 220- 220-NOTE: All file transfers are logged by the relay, and are 220- most likely also logged by the system at the other end 220 of the connection. Name (ftp-gw:): anonymous@gatekeeper.dec.com 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. ... README.nfs ... 226 Transfer complete. 448 bytes received in 0.18 seconds (2.4 Kbytes/s) ftp> get README.nfs 200 PORT command successful. 150 Opening ASCII mode data connection for README.nfs (2799 bytes). 226 Transfer complete. local: README.nfs remote: README.nfs 2853 bytes received in 0.54 seconds (5.2 Kbytes/s) ftp> put README.nfs 200 PORT command successful. 530 Operation denied by FTP gateway ftp> quit 221 Goodbye. Figure 3: Sample interaction with FTP relay. % ftp ftp-gw Connected to ftp-gw 220-FTP passthrough server 220-To connect to a remote FTP server give your login as: 220-user@server.serverdomain (EG: anonymous@host.cs.mumble.edu) 220- 220-NOTE: All file transfers are logged by the relay, and are 220- most likely also logged by the system at the other end 220 of the connection. Name (ftp-gw:): treese@somewhere.edu 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ftp> put fubar 200 PORT command successful. 530 Operation denied by FTP gateway ftp> quote authorize treese 331 Enter response code for 88146: ftp> quote response 35233348 230 Accepted and authorized, 305336 ftp> put fubar 200 PORT command successful. 150 Opening data connection for fubar (192.58.206.2,3441). 226 Transfer complete. local: fubar remote: fubar 20929 bytes sent in 0.035 seconds (5.8e+02 Kbytes/s) ftp> quit 221 Goodbye. Figure 4: Sample interaction with FTP relay using authentication. Given the somewhat relaxed policy described for FTP and telnet above, we cons* *ider access to the NIC WHOIS server. For this application, access to the NIC is suf#cient because it holds t* *he directory of interest. Widespread access to WHOIS servers throughout the network is a different issue. In this ca* *se, the protocol itself is not a means of data transfer, and we wish to provide the service for all internal users. A simple TCP relay that only connects to the NIC suf#ces for WHOIS. It should* * limit access to internal systems, but no access control beyond that is necessary. It does not transfer signi#cant* * data, and an intruder would need to compromise both the NIC and an internal machine to hijack the relay. 6.4Sup sup [15] is a software distribution program developed by the Mach project at * *Carnegie Mellon University. It is used to distribute updates to the Mach software to interested parties who are c* *ooperating with CMU. Suppose we are interested in receiving updates to Mach on an internal system. sup is clear* *ly designed for data transfer, so we cannot provide widespread and unauthenticated access. Since only one internal g* *roup needs to use sup, we can use a TCP relay that admits connections only from their machine and connects only t* *o a designated machine at CMU. An intruder must compromise both ends of the connection to move data through th* *e relay. 6.5Electronic Mail and USENET News Relays are nothing new to electronic mail and USENET news; #store-and-forward* *# systems have been relaying mail through organizational boundaries for years. We believe that these applica* *tions #t well into our framework. The security policy is relaxed to allow use by anyone for inbound or outbound m* *essages. Messages #touch down# on a gateway machine, where sender and destination can be logged. The applicati* *ons are not high in bandwidth because of the usual processing overhead. 7 Other Approaches Application relays are not the only possible means to secure connected but di* *strustful networks. In this section we discuss some alternatives that operate at the network layer, concluding with* * a comparison to our work at the application layer. The approaches described here all interact with the routing * *of a packet through the network. Routing determines the path a packet will take through a network. The path ma* *y traverse several networks and routers. Each router decides what action to take for each packet. This action m* *ay be to forward it to the ultimate destination, forward it to another router, or reject the packet for some reason* * (possibly with a noti#cation to the sender). Most routers today try to select a route that minimizes some metric of* * the path, such as delay or number of routers traversed. Routers could use other considerations in making these decis* *ions. For example, the router might permit only certain senders, or it may forward packets of certain users over hi* *gher-speed links. The alternative approaches discussed here vary primarily in what information is used to make ro* *uting decisions. 7.1Screening Routers As we have discussed, a screening router can be an important component of a #* *rewall system. A screening router permits an organization to implement a variety of security policies [8].* * Unfortunately, a screening router alone cannot always satisfy the administrative policy for a given application. * *Because it has no real knowledge of the application, it cannot perform application-speci#c actions such as those we* * use for xforward. 7.2Policy Routing Policy routing, such as the architecture described by Clark [3], enables rout* *ers to make decisions based on resource policies, including security as well as other considerations such as l* *ink speed or cost. Clark proposes an architecture in which policy routes are synthesized by the source host and its * *administrative domain. The routers along the path are responsible for enforcing the selected policy. In practice, the main problem is that it requires wide deployment of both end* * systems and routers capable of creating and enforcing policy routes. Therefore we could not build a system bas* *ed on policy routing. 7.3Visa Protocols Visa protocols [5] are another approach to managing the #ow of packets betwee* *n organizations. A #visa# is an unforgeable cryptographic stamp attached to a packet. In the same way that a* * passport visa grants permission to visit a country, a packet's visa grants it permission to enter or leave an o* *rganization. Routers at organizational boundaries can check the visa of a packet before forwarding it to verify that i* *t has the appropriate permissions. Visas are issued by trusted access control servers in the source and destinatio* *n organizations. Visa protocols solve many of the problems we have considered so far. However,* * the routers still cannot take action based on the application, which is required for some of the policies we * *have considered. For example, a router would not be able to create the xforward prompt for a new connection, si* *nce it has no knowledge of the protocols it is routing. 7.4Why the Application Layer? Estrin and Tsudik [4] argue that the network layer is the appropriate place f* *or inter-organizational access controls. This conclusion is based on the design principle of the end-to-end ar* *gument [12]. The basic end- to-end argument is that controls should be placed at the highest layer of the n* *etwork at the actual endpoints of the communication, since only the highest layer will actually be able to ensure* * properties such as reliability and security. Estrin and Tsudik note that one may consider entire organizations as * *endpoints in their own right, because the network resources of the organization must be protected as well as the end * *systems within the organization. Because the network layer is the highest normally handled by an organization'* *s border routers, the end-to-end argument places responsibility for security at that layer. We have gone a step * *beyond, however, using application relays on border gateways. Given the application relays, the end-to-end argumen* *t moves the responsibility for security to the relays. Application relays give us the additional #exibility to perform application-s* *peci#c functions # xforward can interactively request approval for a connection, for example. 8 Conclusions and Future Work Building secure and useful inter-organizational networks is a complex challen* *ge. By building application- speci#c relays to satisfy particular administrative policies, we have been able* * to expand the services available to users lacking full access to the Internet. These services preserve the desired * *security of the internal network as well. Not every application is suitable for this kind of relay, but the techniq* *ues work in a surprising variety of situations. In addition to the security issues, these techniques can be useful when routi* *ng issues would normally prevent access between networks. For example, if an organization uses a single network * *number for its internal network, it is limited to a single primary route from the Internet into the organization* *'s network, even if it has several points of connection. The application relays hide this problem from the end systems. As the range of services available on the Internet grows, we hope to be able * *to make many new services available on protected networks by applying these techniques. Although the impl* *ementation often varies from application to application, making it dif#cult to reuse source code, each new a* *pplication is easier to construct because it builds upon the cumulative experience. Much work remains to be done,* * however, in making this process more straightforward and automatic. Although the telnet and ftp relays do eliminate the need for user accounts on* * the gateway, the current version of xforward does not. In order to eliminate the need for user accounts, we need* * a method for users to invoke the X relay remotely, without having a user account on the #rewall. We might accompli* *sh this in two ways: #rst, we can build a listener that will accept xforward invocation requests from internal ma* *chines, on the theory that anyone on an internal machine should have authorization to use the X relay. If this does * *not meet the administrative security requirements, in addition we can make use of #smart cards#, to verify that the * *requester is in fact authorized to remotely invoke the X relay. All of the relays we have implemented use TCP. For TCP applications, the rele* *vant security decisions can usually be made at connection creation time. Application-speci#c relays can als* *o be built for applications that use UDP. For UDP applications, the relay's decision whether or not to forward w* *ould have to be made packet by packet, rather than per connection. This would require detailed information abo* *ut the application speci#c protocol layered on UDP. This is similar in spirit to what the FTP relay does when it ch* *ecks each FTP command before passing it through. On a more practical note, we are planning to extend xforward to support compr* *ession of the X protocol for use over low-bandwidth network connections. We also plan to add an interactive cont* *rol panel that will display status information and allow users to modify the access lists during execution. 9 Acknowledgements The authors would like to thank John Kohl for implementing the original TCP f* *orwarding code now used in xforward; it had no particular security features. Brian Reid forced us to caref* *ully work through the security issues surrounding xforward. Marcus Ranum designed and implemented the FTP and Telnet * *relays and has provided much helpful discussion on these issues. Victor Vyssotsky gave us the freedom t* *o experiment carefully with the InternetgatewayatDigital'sCambridgeResearchLab. NeilFishmanandTedWojcikassisted* *withourexperiments at CRL's gateway. We would like to thank Murray Mazer, Larry Stewart, Jim Mille* *r, and the USENIX referees for helpful comments on this paper. References [1]S. M. Bellovin. Security problems in the TCP/IP protocol suite. Computer Co* *mmunications Review, 9(2):32# 48, April 1989. [2]Bill Cheswick. The design of a secure internet gateway. In Proceedings of t* *he USENIX Summer Conference, 1990. [3]David D. Clark. Policy routing in internetworks. Internetworking: Research * *and Experience, 1:35#52, 1990. [4]D. Estrin and G. Tsudik. An end-to-end argument for network layer, inter-do* *main access controls. Internet- working: Research and Experience, pages 71#86, June 1991. [5]DeborahEstrin,JeffreyC.Mogul,andGeneTsudik. Visaprotocolsforcontrollinginte* *r-organizationdatagram #ow. IEEE Journal on Selected Areas in Communication, 1989. [6]K. Harrenstien, M. K. Stahl, and E. J. Feinler. NICNAME/WHOIS. RFC 954, Net* *work Information Center, October 1985. [7]Jeffrey C. Mogul. Simple and #exible datagram access controls for UNIX-base* *d gateways. In Proceedings of the USENIX Summer Conference, pages 203#221, Baltimore, MD, June 1989. [8]Jeffrey C. Mogul. Using screend to implement IP/TCP security policies. Tech* *nical Note TN-2, Digital Equipment Corporation Network Systems Lab, 1991. [9]J. B. Postel and J. K. Reynolds. Telnet protocol speci#cation. RFC 854, Net* *work Information Center, 1983. [10]J. B. Postel and J. K. Reynolds. File transfer protocol. RFC 959, Network I* *nformation Center, 1985. [11]Marcus J. Ranum. A network #rewall. In Proceedings of the World Conference * *on System Administration and Security, Washington, D.C., July 1992. [12]J. Saltzer, D. Reed, and D. Clark. End-to-end arguments in system design. A* *CM Transactions on Computer Systems, 2:195#206, 1984. [13]Herve Schauer and Christophe Wolfhugel. An Internet gatekeeper. In UNIX Sec* *urity Symposium III Proceed- ings, pages 49#61. USENIX, 1992. [14]Robert W. Schei#er and James Gettys. X Window System. Digital Press, Bedfor* *d, MA, 3rd edition, 1991. [15]Steven Shafer and Mary Thompson. The SUP software upgrade protocol. Availab* *le by anonymous FTP from mach.cs.cmu.edu:/pub/sup/sup.doc. [16]Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Schiller. Kerberos: An* * authentication system for open network systems. In Proceedings of the USENIX Winter Conference, pages 191#2* *02, January 1988. [17]J. Tardo and K. Alagappan. SPX: Global authentication using public key cert* *i#cates. In Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, pages 2* *32#244, Oakland, CA, May 1991. [18]HubertZimmermann. OSIreferencemodel#theISOmodelofarchitectureforopensystems* *interconnection. IEEE Transactions on Communications, Com-28(4):425#432, April 1980. G. Win#eld Treese is a member of Digital Equipment Corporation's Cambridge Re* *search Laboratory and a graduate student at the MIT Laboratory for Computer Science. Prior to joining D* *igital he worked at MIT Project Athena. He is currently working on high-performance networks. Win holds an S.B.* * in Mathematics from MIT and an S.M. in Computer Science from Harvard University. His electronic mail ad* *dresses are treese@crl.dec.com and treese@lcs.mit.edu. His postal address is Digital Equipment Corporation, On* *e Kendall Square, Building 650, Cambridge, MA, USA 02139. Alec Wolman is a graduate student at the University of Washington, currently * *on leave from Digital Equipment Corporation's Cambridge Research Lab. He holds an A.B. in Computer Science from* * Harvard University. His electronic mail addresses are wolman@cs.washington.edu and wolman@crl.dec.com. * * His postal address is: Computer Science and Engineering, University of Washington, Sieg Hall, FR-35, S* *eattle, WA, USA 98195. A xforward Manual Page