Securing Ordinary TCP Services through Tunnels

Manfred Bogen
Michael Lenz
Andreas Reichpietsch
Peter Simons

April 17, 1998

Abstract:

Many popular protocols deployed in the Internet today, have been designed years before security, cryptographic authentication and data encryption was an issue. Examples for such protocols are POP, telnet, X11-remote-display, and FTP. These protocols are to be considered insecure nowadays and if we were living in an ideal world, they would have been replaced by more sophisticated protocols completely.

In fact, though, Internet services based on these protocols are used more than ever before, because of the widespread availability of implementations for all platforms and operating systems. A large organization or company can not afford to discontinue services like POP or FTP, because so many of their members or employees are using them.

The solution for this dilemma is to tunnel the insecure protocols through secure channels, which are protected by strong cryptography. Even though software for this purpose is widely available already, the Secure Shell (SSH) for example, experience has shown that the concept of tunneling is not easy to understand.

In this paper, the authors will explain the concept of tunneling TCP connections through secure channels in great detail. Furthermore we will provide several examples, how tunneling can be implemented transparently for the users of a system, explain the necessary changes in the configuration of the server- and the client-side of the service, and discuss the problems that arise when tunneling is used through a firewall.

During our work in the German National Research Center for Information Technology (GMD), we have also measured the performance penalty that arises from encrypting and possibly compressing frequently occurring TCP connections and will present the results here.

The paper has been written mostly for the administrators and users of Unix and Windows NT workstations, but only very few parts actually depend on the deployed operating systems. The underlying concepts of tunneling are valid for all kinds of operating systems and software implementations.

Security, Cryptography, SSH, Unix.

1 Introduction

The Internet was designed to provide a robust transmission facility of data packets that remains in operation even if parts of the infrastructure are out of service or not available. Security was neither a major issue while defining the underlying protocols nor while defining many applications on top of TCP/IP.

Although the fundamental vulnerabilities of computers that are connected to the Internet were known for a long time, the flaws have rather been accommodated than corrected. As a result, within the recent years many cases of wide scale security infractions have occurred.

However, many users connected to the Internet rely on services like POP, SMTP, telnet, and X11 despite their immanent security risks. Even more, without using them there would almost be no reason to connect to the Internet at all.

Security enhanced versions are available for some of the vulnerable services, but not for all of them. In addition, they are not widespread within the Internet. One possible solution to overcome these drawbacks, as described throughout this paper, is the use of TCP-based tunneling solutions.

The paper is structured as follows: After categorizing different types of attacks to TCP-based protocols (section 2), section 3 describes how tunnels operate in principle. Section four presents an overview about available software solutions. Section five and six respectively deal with tunneling simple and complex protocols and electronic mail. Potential problems and performance penalties by using tunnels are discussed in section 7. Section 8 describes some alternative solutions to application-level tunneling while section 9 concludes the paper.

2 Insecure Protocols and Services

2.1 What is a ``service'' in the Internet?

Before we take a look at the technical details, it is important to clarify the terminology used throughout this paper. The term ``service'' is used to denote an Internet-specific application like the exchange of electronic mail, the transfer of a file from one machine to another through the network. These services are based on specific ``protocols''. Electronic mail is exchanged with the Simple Mail Transfer Protocol (SMTP), files are transferred via the File Transfer Protocol (FTP), etc.

The protocols discussed in this paper are based on TCP/IP, the protocol stack of choice in the Internet. That is, a TCP connection is opened from one machine to the other, and the protocol- or application data is transferred through it. In the Internet, other type of protocols layers exist, for example UDP or Multicast transmissions, but those are beyond the scope of this paper.

Every TCP-based service in the Internet is identified via an unique ``port number''. When a client initiates a connection to a server, it chooses to connect to, say, port 25 on the remote machine. According to [RFC 1700], port 25 is assigned to the SMTP protocol and thus to the service of delivering an electronic mail.

Most well-known and popular services are assigned a port number in the range from 0 to 1024, but the valid port numbers range from 0 to 65535.

Throughout our text, we will use the name of the protocol in question to denote the TCP port associated to this protocol and the service for which the protocol is deployed. Only when the context might be misleading, the accurate distinction between the service, the protocol or the port number will be made.

2.2 Security Threats

Many of the popular TCP-based Internet services used today were not deployed with security as a primary goal. So, they suffer from various potential security threats.

2.2.1 Sniffing

In the recent years, sniffing has become a pressing problem. IP packets are transferred on a hop-by-hop basis. So, they can be intercepted by all intermediate hosts. In addition, these packets are generally transferred via broadcasting media within local networks. Thus, every host can eavesdrop all data packets on the network it is directly attached to.

Unfortunately almost every popular and widespread Internet service like SMTP, POP, HTTP, telnet, the r-commands, and X11 transmits its data in clear text, thus allowing to eavesdrop sensitive or private information. Even worse, many of these services rely on a password based authentication scheme at which accounts and passwords are also transferred in clear text. In the case of POP e.g. the password is transferred every time the POP client accesses the server, which normally happens every few minutes.

Due to their passive nature sniffers can practically not be detected. Supporting all kind of TCP/IP-based application protocols, they are quite convenient to use. They can store the intercepted information locally over a long time so that there is no need to initiate frequent connection requests to forward the data which could be traitorous.

2.2.2 Connection Hijacking

After a successful establishment and authorization, an attacker can try to take over the connection. Target of this very technical attack are terminal or login services, like e.g. telnet. The stolen connection can then be used to initiate requests with the access rights of the originating user and to intercept the replies.

2.2.3 False Authentication

Many services require no authentication at all or rely solely on IP addresses or domain names: Quite often SMTP servers accept e-mail messages from any host without authentication. The same holds for anonymous FTP as well as Web and gopher servers (as long as they do not offer access to restricted documents). All these services are subject to command channel attacks where ordinary protocol commands are used to exploit security breaches.

In addition services like SMTP can also be used for data driven attacks. In the case of SMTP the service may be subverted for mail bombing or for distributing (macro) viruses.

The rlogin and rsh service rely on trusted hosts and/or trusted users to grant access to the system without requesting a password. Also FTP or Web servers can be configured in such a way that they allow access to restricted data to specific hosts. But relying on IP-addresses or domain names provides no real protection. IP addresses can be spoofed and even reverse or double reverse look-ups of DNS information does not offer substantially more security as DNS entries can also be forged quite easily by an experienced attacker.

2.2.4 Data Spoofing

Beside passively monitoring a network (i.e. sniffing) an attacker can also manipulate transmitted datagrams or inject new ones. In general all clear text protocols and services are vulnerable by this kind of attacks.

Being able to monitor all passing traffic and to connect to a service (e.g. via IP spoofing) also opens an avenue for replay attacks where parts of an ongoing legal communication are recorded and replayed lateron.

2.2.5 Implementation and Configuration Bugs

But even with a perfectly secure design a service may suffer from implementation bugs like e.g. a buffer overflow which may be used to gain access to the host. In the context of Web servers poor CGI scripts which pass user provided data to a command shell without carefully checking are wide open avenues for attackers.

Additional security breaches may result from misconfiguration. A poor configuration of an anonymous FTP server e.g. may put the whole machine on risk.

2.2.6 Denial-of-Service Attacks

By launching a denial-of-service attack an existing service is made unavailable to its authorized users. This can be achieved by flooding the server with faked connection requests, like the popular SYN-flood attack. While the flooding takes place, the attacked host is virtually detached from the network.

Other attacks are protocol specific. SMTP messages received for local users are ordinarily stored on local disk. Hence by flooding a SMTP server with e-mail messages the service can be made unavailable for other users and in addition the local file system can be filled up entirely. But this is not a SMTP specific problem, virtually every externally accessible service can be made unavailable by flooding it with requests.

3 What is ``Tunneling''?

The idea of tunneling insecure protocols is to identify networks, that are assumed to be secure. A company's internal network, for example, is usually protected by a sophisticated IP packet filter or firewall software, rendering all attacks to the inside of the network infeasible. The outside network, on the other hand, is known to be insecure.

Let us, for example, contemplate what happens when an employee of the company accesses his electronic mail at work from his private workstation through the Internet, using the insecure [POP3] or [IMAP] protocols. His user password and the contents of the e-mail are not protected and may be eavesdropped.

This is a serious security threat not only to the privacy of the employee, but also for the security of the company and the company's internal network. Of course, eliminating this threat is simple: Just disallow the employee to read his e-mail at home by configuring the packet filter mechanism appropriately. Unfortunately this may be infeasible as employees might be required to access their electronic mail through the Internet from wherever they are.

A secure tunnel is the appropriate solution for this dilemma. The concept of tunneling is illustrated in figure 1 below.

  
Figure 1: How do tunnels work?

To stick with the mail-reading example from above, let us say that a user wants to read e-mail on server A, B, or C, using the insecure POP3 protocol. Instead of connecting directly to the server machine at TCP port 110, he or she opens a secure connection from the client machine to the tunnel server. This secure connection is made with a special tunneling software, that features strong encryption and authentication.

The tunneling software, once started at the client machine ('Private Workstation'), listens to, say, TCP port 5000. All communication requests are forwarded through the encrypted tunnel to the tunnel server, which in turn decrypts the incoming data and forwards it to the mail server at port 110.

Now the users configure the POP3 software to connect to localhost, port 5000 and engages the mail-fetching process. The POP3 connection is now tunnelled through the insecure network by the tunneling software and then transparently forwarded by the tunnel server to the mail server again.

This works as follows: Both the client and server software speak plain and insecure POP3 with each other, being completely unaware of the tunnel server and the functionality it performs. The mail-fetching process works just fine with the normal, unmodified POP3 programs.

Due to the tunnel, all data transmissions between the client machine and the tunnel server are encrypted and have been authenticated properly. The transmission between the tunnel server and the mail server is an ordinary POP3 connection, but it lies within the secure company network and can not be eavesdropped or abused otherwise.

This approach fixes two important problems:

1. The insecure POP3 protocol can be used in a secure fashion, using the well-known software.
2. The packet filter or firewall software, protecting the company network does not need to have any holes to allow employees to read their electronic mail. The packet filter needs to allow only connections to the tunnel server — nothing else. And this interface is secure due to the functionality of the tunneling software.

4 An Overview of Available Software Solutions

Various software packages exist, that implement tunneling functionality. In the following sections we shall introduce the most common solutions.

4.1 Secure Shell (SSH)

The Secure Shell (SSH) can be found at [SSH]. Versions exists for the Unix (including full source code) and Windows operating system. For new users, a brief tutorial can be found at [SSH-TUT].

The SSH is not exactly a tunneling software. In fact, the ability to tunnel connections securely is only a by-product of SSH's other capabilities. Mainly, the Secure Shell is a replacement for the well-known telnet, rlogin and rcp services. SSH uses strong cryptography (RSA, IDEA, 3DES and other algorithms) and authentication to allow users to log into a Unix machine remotely. SSH's protocol protects against all attacks described in the first section. It also features the ability to open secure tunnels as described in the second section.

In our paper, we will use the SSH to demonstrate the real-world applications of tunneling connections, because it is a very sophisticated and useful tool, which is available for free for Unix users.

4.2 Secure Socket Layer (SSL)

The Secure Socket Layer Protocol, developed by Netscape, has become a de facto standard. SSL implements an additional layer between TCP and the application layers (FTP, HTTP, SMTP, …). Complete authentication and encryption happens in the Secure Socket Layer. For using SSL, special client and server programs are needed. The applications are not involved, there are no changes necessary and all standard application programs will work.

SSL connections are built up in two phases. A handshake protocol is started, server and client agree on an encryption method and key. The server sends its certificate [X.509] for authentication — optional client authentication is possible. Also, various public key encryption methods are available and different kinds of hash functions can be chosen.

After the server certificate is verified (and optionally the client is authenticated via the client certificate), an encryption method is selected. A session key is exchanged via public key encryption or token-based encryption systems. This session key can use one out of a number of secret (symmetric) key algorithms for encrypting the session.

Now phase two begins. The proper session starts, the message is fragmented into blocks, a MAC (message authentication code) is used, the single blocks (packets) are encrypted and transmitted. On the other side the received packets will be decrypted, verified, put together and delivered up to the higher levels. Client and server certificates use X.509. This enables a complete authentication of both, client and server, and prevents against man in the middle attacks. [SSL3]

Most commercial available products use 40-bit RC4 keys for session encryption. This is forced by the US encryption export laws. But there are also free available products which use strong encryption too.

A well known application of SSL is HTTPS, but other programs like sslftp or ssltelnet are available on the Internet (see [CERT]). A widespread Web server with an optional SSL extension is the [APACHE] Web server.

5 Real-world Examples of Useful Tunnels

The following applications for secure tunnels are real world examples, that fulfill useful functions in the authors' every-day work. We have emphasized the practical aspects of these tunneling examples and present actual implementations for the Unix operating system, using the Secure Shell, SSH.

All examples can be used in an Windows environment with the SSH, too. The differences in the SSH's user interface are trivial as all the concepts are exactly the same.

5.1 Tunneling Simple Protocols

A ``simple protocol'' is one that uses only one TCP connection to perform all its functionality. Most protocols used in the Internet today are of this type and tunneling them is pretty easy, once one got used to the way this is accomplished.

5.1.1 POP3

POP3 is used to transfer electronic mail from the mail server to the local machine and is typically implemented in the mail reader. In our example, the mail server is called mail.my.org and the tunnel server is called tunnel.my.org.

Now an user wants to get his e-mail from the company mail server to his private work station through the Internet. First of all, the tunnel needs to be opened. This is achieved by executing the following command:

 $ ssh -L 110:mail.my.org:110 tunnel.my.org

The SSH will now log into the tunnel server and open the tunnel. For this to succeed, the user needs an accessible shell account on the server, in which he can log into. This may be a personal account, or a generic account to which all employees have access. The authors recommend to use personal accounts, because this gives more power to the server administrators, to control what is going on on their machines.

What happens now is this: When the login succeeded, SSH will start to listen to port 110 (POP3) on the local machine, that is the private workstation of the user. Every connection that arrives there, is tunnelled through the secure connection to tunnel.my.org. The tunnel server will then forward the connection to the machine mail.my.org, to port 110.

So all the user has to do is to tell his mail client, that the POP3 server to query for e-mail is the local machine: localhost.

The tunnel can also be tested using the command:

 $ telnet localhost pop3

which will be answered like this:

Trying 127.0.0.1 ...
Connected to localhost.my.org.
Escape character is '^]'.
+OK QPOP (version 2.2-b7) at mail.my.org starting. \
        <[email protected]>

If the tunnel works correctly, the server answering the connection will be the intended machine, even though the TCP connection was originated with localhost as target.

5.1.2 IMAP

If the user uses the IMAP protocol, rather than POP3, the whole process is identical except for the port numbers. The command to open the tunnel is now as follows:

 $ ssh -L 220:mail.my.org:220 tunnel.my.org

5.1.3 Telnet

 

Of course a normal telnet session can be tunnelled, too. The corresponding port is 23. So if one wants to telnet into the server server.my.org, this command will open the tunnel:

 $ ssh -L 23:server.my.org:23 tunnel.my.org

To start the telnet session, execute:

 $ telnet localhost

Obviously, there is little point in tunneling a telnet session to a Unix server. One should rather log into that machine with the SSH directly, which is easier and adds additional benefits the SSH provides. But still there are enough machines that can not be equipped with an SSH server, for example ISDN routers, which frequently need to be accessed with telnet.

5.2 More Complex Protocols

A ``complex'' protocol is one that uses more than one TCP connection. A good example for this is the File Transfer Protocol (FTP) discussed below. Tunneling of complex protocols can be tricky or flatly impossible.

5.2.1 FTP

The FTP protocol uses two connections: A control channel and a data channel. Over the control channel, the user logs into the FTP server, browses through the available files or issues any GET or PUT commands. Once such a command has been given, the FTP server and client open up a second channel over which the actual data transmission takes place. When the file transfer is over, the data channel is closed and control is given to the control channel again.

The problem when trying to tunnel FTP is that it is not possible to predict, which ports will be used for the data channel. The control channel is always opened at port 21, but the data channel may use any port that is available and the actual number is negotiated between the client and the server on the fly.

So it is possible to tunnel the control channel, thus securing the login and password of the user. But the actual data transmission will take place without protection. Protecting the user and password information is better than nothing but the authors recommend to consider using the SCP tool provided in the SSH distribution, to replace FTP for file transfers completely, when sensitive data has to be exchanged.

5.2.2 X11 Displays

An important feature of the graphical interface X11 is the ability to forward graphical objects, like windows, through the network to a remote machine.

Such transmissions can be secured with SSH, too, even though this is not achieved with the usual tunnel approach. The SSH login tool has an in-built X11 forwarding mechanism, which does this transparently. When logging into a remote server with the SSH, a pseudo display is set up there and the $DISPLAY environment variable is set automatically.

As a result, all started programs will open their displays as usual, but internally, the transmission is tunnelled through the connection without any further effort.

6 Tunneling Electronic Mail

A rather unexpected, useful application of tunneling is the protection of company internal electronic mail. For the sake of the example, let us contemplate an imaginary company of the name ``Big Bucks''. Big Bucks has two major departments, which are located in Tokyo, Japan and Birlinghoven, Germany respectively. The corresponding Internet subdomains for each department are tokyo.big-bucks.com and birlinghoven.big-bucks.com.

Naturally, e-mail is used a lot for internal communication between the two departments of the company, but the problem is that this mail is routed through the insecure Internet and consequently is subject to eavesdropping or even modification. Because many of the employees of Big Bucks are non-technicians, it is not suitable to enforce that all e-mail is sent encrypted.

A simple SSH tunnel between the two divisions of Big Bucks can solve this problem easily and comfortably. We will describe the set-up below.

1. Each department needs a dedicated mail server: mail.birlinghoven.big-bucks.com and mail.tokyo.big-bucks.com respectively.
2. All machines are configured to deliver all non-local mail to the mail server. This can be assured by blocking outgoing connections to the SMTP port (25) via an IP packet filter or firewall software.
3. mail.birlinghoven.big-bucks.com and mail.tokyo.big-bucks.com will deliver outgoing mails for recipients in the Internet, or within the division's network, as usual.
4. mail.birlinghoven.big-bucks.com will send all e-mail directed to the tokyo.big-bucks.com division to mail.tokyo.big-bucks.com and vice versa. This delivery, though, is carried out through a secure tunnel.

In this set-up, all company internal e-mail is transparently protected against eavesdropping or modification — the employees of Big Bucks need not even be aware of this measure!

6.1 The Tunnel

Practically, this set-up is realized as follows. We are assuming, the standard Unix sendmail program, version 8 is installed. The tunnel is done via SSH.

Opening the required tunnels is nothing really new, so we will keep the description briefly. On mail.birlinghoven.big-bucks.com, the tunnel to mail.tokyo.big-bucks.com is opened by logging into the other machine with the command

 $ ssh -L 5000:mail.tokyo.big-bucks.com:25 \
        mail.tokyo.big-bucks.com

and the other way round is as easy:

 $ ssh -L 5000:mail.birlinghoven.big-bucks.com:25 \
        mail.birlinghoven.big-bucks.com

6.2 The Sendmail Configuration

Configuring sendmail is a bit more tricky. First of all, it is essential that all machines are configure to relay all outgoing mail via the appropriate mail server. With sendmail, this can be accomplished by adding the following statement to the M4 configuration file:

define(`SMART_HOST', `esmtp:[mail.birlinghoven.big-bucks.com]')

or

define(`SMART_HOST', `esmtp:[mail.tokyo.big-bucks.com]')

On other platforms, most notably Windows, this setting has to be made in the user's mail reader, for example Netscape, so we will not describe it here.

Now we need to configure the mail servers. Both of them use the following M4 file to create the sendmail.cf:

divert(-1)
include(`../m4/cf.m4')
OSTYPE(bsd4.4)
MAILER(smtp)
Mtsmtp,         P=[IPC], F=mDFMuX, S=11/31,
                R=21, E=\r\n, L=990,
                T=DNS/RFC822/SMTP, A=IPC $h 5000
FEATURE(mailertable, `hash -o /etc/mail/mailertable')

This configuration file is pretty normal, except for the definition of the new mailer type ``tsmtp''. ``tsmtp'' is the ordinary ``smtp'' driver, included in sendmail, except for the fact, that it will connect to port 5000, rather than port 25.

Please note that this sendmail still behaves perfectly normal. Mail is delivered with ``ordinary'' SMTP or ESMTP to the usual ports. The only addition is a mailer, that uses port 5000 instead.

Now comes the crucial part: On mail.tokyo.big-bucks.com, the following file will now be installed in /etc/mail/mailertable:

.birlinghoven.big-bucks.com  tsmtp:[mail.tokyo.big-bucks.com]

and then the command

 $ makemap hash /etc/mail/mailertable.db </etc/mail/mailertable

is executed.

For mail.birlinghoven.big-bucks.com, the appropriate file is:

.tokyo.big-bucks.com  tsmtp:[mail.birlinghoven.big-bucks.com]

All e-mail addressed to recipients outside big-bucks.com is delivered through the normal (E)SMTP client of sendmail. All other mail stays either inside the secure company network or is tunnelled securely through the Internet, to the other department's mail server.

7 When Using Tunnels

7.1 Problems

There are various pitfalls that may cause trouble when using tunnels, in particular with the SSH software:

• On some machines, the SSH is compiled with the [TCPWRAP] option included. TCP Wrapper is a program that controls, who may connect to certain services on the local machine. Even though this is not obvious at first, this also affects the ability to open tunnels on that machine.

  The tricky bit is that the SSH connection will succeed just fine and everything looks okay at first. But every time someone tries to use the tunnel, the connection will abort without further comment, if TCP Wrapper disallows it. So if you are experiencing problems using the tunnel, it is a good idea to specify the -v flag of SSH, when logging into the remote machine.

  This will turn the ``verbose-mode'' on, giving you a more detailed description of what happens, and what does not happen.

• In the default configuration, the SSH binary will be installed with owner ``root'' and the ``setuid'' bit set. This is necessary for the SSH to take advantage of the common ``rhosts'' mechanism in Unix. In order to allow rhosts-authentication, the client must engage the connection from a trusted port — a port number lower or equal to 1024 that is, and these ports can only be used as superuser.

  The problem that arises from this behaviour is that many company networks are protected by a IP packet filter or firewall software and the default configuration of these programs is to deny outgoing and incoming connections from or to a port lower or equal to 1024. Hence, if you attempt to log into the remote machine with SSH, it will fail, even if you're not using the rhosts-mechanism at all.

  The solution is to either remove the ``setuid-root'' bit from the SSH binary, or to set the following configuration options in /etc/ssh_config:

  RhostsAuthentication no
  

  Then the SSH will not use the trusted ports for outgoing connections anymore.
• In section 5.1.3 an example of tunneling a telnet session was shown. In the example, the tunnel was opened at the local machine on port 23. This is convenient, because port 23 is the port assigned to the telnet service and hence, a simple telnet localhost command would deploy the tunnel as intended.

  Often this will not be possible, though, because the local port 23 is already allocated by the telnetd program, the software that accepts incoming telnet connections and handles them. The same is true for an attempt to tunnel a POP3 connection from the local machine to some remote server, using port 110. If the local machine supports the POP3 service, too, then port 110 will be allocated already and opening the tunnel will fail.

  Fortunately the solution is rather easy. Instead of opening the local end of the tunnel at the port that is commonly assigned to the service, one can use a random, free port number instead, for example port 5000. The only difference in this case is that the client software, which initiates the connection, must connect to port 5000 instead, rather than the port number assigned to the service usually.

  With almost any modern client software, the port number to connect to can be configured at run time, so that this doesn't pose a problem.

7.2 Costs

An interesting point to check is, what encryption will cost. To get some ideas how encryption slows down the transmission, we set the follwing experiment up:

A file of 7375432 byte was transported between different hosts using the built-in rcp and the scp command from the ssh-distributon. The times were stopped for the whole rcp/scp command, both processes used .rhosts for login authentication.

The ssh programs were compiled without any additional optimization, we used our normal inhouse network, the hosts were connected via hubs and switches. SSH was configured not to use compression. The used encryption algorithm was IDEA.

At first, the speed loss due to encryption may be surprising, but it is clear that the loss suffered from the additional encryption phase becomes more substantial, the faster the network is. Practically, this is not a big problem as the average network transmission hardly exceeds the 10 MB/second rate in the Internet.

Furthermore, the choice of the encryption algorithm greatly influences the performance. IDEA is considered to be the most secure algorithm of those, available in the SSH. That's why we used it in our tests, even though it is one of the slowest, too. Other algorithms, for example ``Blowfish'', are known to be a lot faster, at the cost of some security.

8 Alternative Solutions

There are two fundamentally different approaches to secure transactions through the Internet: The one we described so far is on application-level, the other one works on network-level. Both approaches have their advantages and disadvantages.

8.1 IPv6

In contrast to the method described so far by encrypting complete sessions/associations between humans and applications, there is also the possibility to encrypt on packet level. A new IP packet type is added to the normal IP protocol, with security built into each packet.

IPv4 and IPv6 use two specific headers in IP datagrams to provide security services: the "IP Authentication Header (AH" and the "IP Encapsulating Security Payload (ESP)" header. Both headers are used alternatively or in combination to maintain a Security Association (SA) for each destination network or host. The SA is identified by a particular destination address and a set of security parameters (Security Parameter Index, SPI) like authentication algorithm, encryption algorithm, or keys.

The IP Authentication Header (AH) is designed to provide integrity and authentication without confidentiality to IP datagrams. It holds authentication information for its IP datagram. It does this by computing a cryptographic authentication function like keyed MD5, DES, or CBC over the IP datagram and using a secret authentication key in the computation. The sender computes the authentication data prior to sending the authenticated IP packet. The receiver verifies the correctness of the authentication data upon reception. Certain fields needed for the transport of the datagram are omitted from the authentication calculation. Use of the Authentication Header will increase the IP protocol processing costs and the communications latency.

The IP Encapsulating Security Payload (ESP) is designed to provide integrity, authentication, and confidentiality to IP datagrams. It does this by encapsulating either an entire IP datagram (Tunnel-mode) or only the upper-layer protocol (e.g. TCP, UDP, ICMP) data inside the ESP (Transport-Mode), encrypting most of the ESP contents, and then appending a new clear text IP header to the now encrypted Encapsulating Security Payload. The encapsulating security approach used by ESP can noticeably impact network performance in participating systems, but use of ESP should not adversely impact routers or other intermediate systems that are not participating in the particular ESP association. Use of encryption will also increase the communication latency.

Several key management systems will be usable with AH and ESP, including manual key configuration. Both of these IP mechanisms can be used to increase the security provided by firewalls. Finally, the Security Parameters Indexes (SPIs) used in the IP security mechanisms, are receiver-oriented, making them well suited for the use in IP multicast (e.g. MBone).

8.2 VPN

Big vendors like [INTEL98] see the Virtual Private Network Technology (VPN Technology) as a first step towards building Internet-based networking in general by enabling secure, private networking among LANs at multiple company sites. The reasons for implementing this technology are not only security requirements, but also include cost, quality of service and bandwidth issues.

Virtual Private Networks (VPNs) are implemented by encryption software used between a firewall or router and communicating entities. Because VPN software typically operates at the network level, all application protocols like ``FTP'', ``HTTP'', or ``SMTP are encrypted transparently. The firewall/router with VPN software simultaneously provides security services and encryption. LAN protocol traffic is encrypted and encapsulated in the TCP/IP protocol over the tunnel and then re-encapsulated in the WAN protocol being used on the real WAN link.

VPNs will play an important role in the future by enabling secure communication and co-operation in and between organizations even over unsecure networks like Internet.

8.3 Simple Key-Management for Internet Protocols (SKIP)

``Simple Key-Management for Internet Protocols'' was developed by Sun Microsystems, but the patents held by Sun were placed into the public domain, so SKIP became an open standard.

SKIP handles security over the network layer, what makes the encryption to be completely invisible for the applications and the user. All packets between two hosts will be encrypted. The IP header of SKIP packets have a protocol header field of 57, while TCP got 6 or UDP got 17 assigned by the Internet Assigned Numbers Authority (IANA). The encrypted datagrams and the SKIP header, preceded by an IP header, can be routed through every standard IP network.

The main goal of SKIP is to implement a usable key management. Each host generates his own Diffie-Hellman (see [DIFFIE]) key pair and gets the public key certified by a certification authority (CA).

Both hosts compute the same shared secret, using only the information in their own secret and the other side's public key. This shared secret will not be used to encrypt the traffic data directly. It is used as a kind of master key in the further encryption process. Each IP datagram is encrypted with a random traffic key, using lightweight symmetric algorithms like DES, RC2, or triple DES. This traffic key is encrypted with the long life shared secret using a strong symmetric encryption algorithm. The traffic key may be changed during the established connection due to a security configuration or policy. SKIP is a sessionless protocol. Asynchronous communication protocols as UDP, ATM, ADSL, multicast traffic or satellite links can be handled with it.

The use of certified DH keys allows host authentication. No central key management station is needed, if all hosts are certified. Nevertheless, SKIP may allow (due to configuration) new stations to enter the SKIP community with dummy certificates.

There exist freely available implementations of SKIP for SunOS, Linux and FreeBSD. Commercial implementations are available for several operation system (see [SKIPSW]).

9 Conclusion

Network coupled security, as SKIP uses, is the conceptionally superior approach when it comes to protecting everyday data transmissions over the Internet. Unfortunately it may still take several months or even years from now, before VPN technology reaches the acceptance and sophistication required for every-day usage.

Until then, secure tunnels are a good way to protect network transmissions now. The administrative effort of opening secure tunnels up is negligible and for many applications, tunneling can be done transparently, without the user knowing about about it at all.

The costs in terms of performance are acceptable, especially with the CPU power of computers growing constantly. For high-speed networks like ATM, a hardware implementation of the encryption algorithms would reduce the performance loss even further.

To sum up the experiences made: there is no reason to accept the defects of insecure or older protocols because tunnels are available now.

References

ANON97

Anonymous: Maximum Security, Sams.net Publishing, 1997

APACHE

The Apache HTTP Server Project, http://www.apache.org/

AVIEL97

A.D. Rubin, D. Geer, M.J. Ranum: The Web Security Sourcebook, Wiley Computer Publishing, ISBN 0-471-18148-X, 1997

AZIZ

A. Aziz, M. Patterson: Simple Key-Management for Internet Protocols, http://skip.incog.com/inet-95.html

CARONNI

G. Caronni, H. Lubich, A. Aziz, T. Markson, R. Skrenta: SKIP — Securing the Internet, http://skip.incog.com/wet-ice.html

CERT

ftp://ftp.cert.dfn.de/pub/tools/crypt/

CHBE94

W.R. Cheswick, S.M. Bellovin: Firewalls and Internet Security, Addison-Wesley Professional Computing Series, July 1994

CHZW95

D.B. Chapman, E.D. Zwicky: Building Internet Firewalls, O'Reilly & Associates Inc., 1995

DIFFIE

W.Diffie, M.Hellman: New directions in Cryptography, IEEE Transactions on Information Theory, 1976

GASP96

S. Garfinkel, G. Spafford: Practical UNIX & Internet Security O'Reilly & Associates Inc., 1996

IMAP

J. Rice: Interactive Mail Access Protocol — Version 3, RFC1203, February 1991

INTEL98

Enabeling Secure Virtual Private Networks Over the Internet, http://www3.intel.com/network/doc/np0894/

POP3

J. Myers, M. Rose: Post Office Protocol — Version 3, RFC 1939, May 1996

RFC 1700

J. Reynolds, J. Postel: Assigned Numbers, October 1994

RFC 1825

R. Atkinson: Security Architecture for the Internet Protocol, August 1995

RFC 2196

B. Fraser: Site Security Handbook, September 1997

SKIPREV

http://www.unixreview.com/backissu/sun9712.htm

SKIPSW

http://www.rsa.com/rsa/SWAN/swan_test.htm

SSH-TUT

A. Reichpietsch, P. Simons: Beginners guide to the Secure Shell, http://cryp.to/the-secure-shell/

SSH

Tatu Ylönen: The Secure Shell Home Page, http://www.cs.hut.fi/ssh/

SSL3

The SSL Protocol Version 3, http://www.netscape.com/newsref/std/SSL3.0/

TCPWRAP

Wietse Venema, TCP Wrapper, ftp://ftp.win.tue.nl/pub/security/index.html

X.509

ITU-T: Recommendation X.509: The Directory — Authentication Framework, 1988