IP Security

IP Security

Security extensions to IP bring authentication and privacy to the Internet.

IP is the underlying technology of networks used by the government, academia, and the corporate world, as well as the public Internet, to send myriad types of packets all round the world. Yet, despite the strength of IP as a WAN protocol, security has never been its strong suit.

This layer 3 protocol oversees packet forwarding through different types of networks. But, IP's ubiquity and wide acceptance as the basis for both public and private networks has led to great concern over the issue of security.

Several types of attacks have been known to take place over IP networks. One is called IP spoofing, in which an intruder tries to gain access by changing a packet's IP address to make it appear that the packet came from somewhere else. Other attacks include eavesdropping on an IP transmission. This can be done by using a protocol analyzer to record network traffic. Another type of IP attack involves taking over a session and masquerading as one of the parties involved in the communication.

The IP security problem will probably only get worse as companies rely on the protocol more and more for remote communications. Also, Virtual Private Networks (VPNs), which allow companies to create a private connection over the public Internet, require strong safeguards. Although VPNs do exist to a certain extent today, most industry watchers will tell you that for this concept to really fly, authentication, encryption, and other security measures need to be in place. The hope is that an IETF standard called IP Security (IPSec), an extension to IP, will be the catalyst for private and secure communications over the Internet.

IPSec is actually a suite of protocols being developed by the IETF. The suite includes the Authentication Header (AH), which addresses authentication for IP traffic, and the Encapsulating Security Payload (ESP), which defines encryption for IP data.

The Authentication Header ensures that the packet has not been altered or tampered with during transmission. It can be used in combination with the ESP (if you need privacy as well as verifying authenticity), or it can simply be used to verify the authenticity of a regular IP packet. The AH also allows the receiver to verify the identity of the sender.

Authentication Header

A traditional IP packet consists of an IP header and a payload, which can consist of a TCP or UDP header and data. If the AH is used, it immediately follows the IP header.

The format of an Authentication Header is shown in Figure 1. The first field in the AH is the next header field; this is an 8-bit field that tells which higher-level protocol (such as UDP, TCP, or ESP) follows the AH. The payload length is an 8-bit value that indicates the length of the authentication data field in 32-bit words. The reserved area is a 16-bit field that's not currently in use; this field has been set aside for future use, and therefore is always set to zero.

Figure 1: The Authentication Header (AH) resides between the IP header and the Encapsulating Security Payload (ESP), or other higher-level protocols, such as UDP or TCP. The chief goal of the AH is to let the sending and receiving parties know that the data came from where it says it did, and that it was not changed during transit.

The Security Parameters Index (SPI) and the sequence number fields come next. SPI is a 32-bit number that tells the packet recipient which security protocols the sender is using. This information includes which algorithms and keys are being applied by the sending device.

The sequence number tells how many packets with the same parameters have been sent. This number acts as a counter and is incremented each time a packet with the same SPI is bound for the same address. The sequence number also guards against a potential attack where a packet is copied and then sent out to confuse the sender and receiver.

At the end of the AH is the authentication data, which is a digital signature for the packet. To authenticate users, the AH can use either RSA Data Security's Message Digest 5 algorithm or the U.S. government's Secure Hash Algorithm. The IETF is also looking into other authentication algorithms, such as hashed message authentication code.

Encapsulating Security Payload

ESP is the protocol that handles encryption of IP data at the packet level. It uses symmetric, or secret key, cryptographic algorithms like Data Encryption Standard (DES), and triple DES to encrypt the payload. The default method is 56-bit DES. The only point of concern about which algorithm is used is the current regulations of individual countries. Many governments put a cap on the strength of encryption exported outside their borders.

As shown in Figure 2, the ESP includes several parts, the first of which is the control header that contains the SPI and the sequence number field. The SPI and sequence number serve the same purpose as in the AH. The SPI indicates which security algorithms and keys were used for a particular connection, and the sequence number keeps track of the order in which packets are transmitted.

Figure 2: The Encapsulating Security Payload (ESP) protocol follows a standard IP header (or the Authentication Header, or AH, if (used) and provides encryption and authentication of the packet.

The SPI and sequence number are not encrypted, but they are authenticated. The next few parts of the ESP are encrypted during network transmission.

The payload data can be of any size (subject to the normal limits of IP) because it's the actual data being carried by the packet. Along with the payload data, the ESP also contains 0 bytes to 255 bytes of padding, which ensures the data will be of the correct length for particular types of encryption algorithms. This area of the ESP also includes the pad length, which tells how much padding is in the payload, and the next header field, which gives information about the data and the protocol used.

The last piece is the optional authentication data. This field contains a digital signature that has been applied to everything in the ESP except the authentication data itself.

To decide whether ESP or AH is best, network managers or security officers need to ask whether they only need authentication or if they need both authentication and encryption. Because AH doesn't provide encryption capabilities, if a scenario requires both features, ideally ESP makes better sense since it does offer both authentication and encryption.

Key Management

Together, the IPSec ESP and AH protocols provide privacy, integrity, and authentication of IP packets, but they are not the complete package. To round out the standard, the IETF also includes a protocol that provides several services, including negotiating which protocols, algorithms, and keys will be used in a communication; verifying the identity of the other party; and managing and exchanging keys.

The Internet Security Association and Key Management Protocol (ISAKMP)/Oakley key exchange protocol automatically handles exchange of secret symmetric keys between sender and receiver. The protocol integrates ISAKMP with the Oakley method of key exchange.

ISAKMP is based on the Diffie-Hellman model of key generation, in which the two parties share information beforehand to ensure the identity of the other party. Under Diffie-Hellman, two parties generate their own public values, which they send to the other party. The two parties communicate through UDP messages. Each party then takes the public key they received and combines it with a private key. The result should be the same for both parties, but no one else can generate the same value.

Although ISAKMP is an automated method, it does allow for the level of trust in keys to be controlled, much like administrators currently control network passwords and how often they are changed. With ISAKMP, the SPI (that 32-bit number that contains security protocol information for a packet) can be reformatted at specified intervals.

ISAKMP/Oakley supports three methods of key information exchange: main mode, aggressive mode, and quick mode. Main mode establishes what's known as the first phase of ISAKMP SA.

SA, or Security Association, is the method of keeping track of all the details of keys and algorithms in an IPSec-compliant session. The SA includes a wide range of information, including the AH authentication algorithm and keys, the ESP encryption algorithm and keys, how often keys are to be changed, how communications are authenticated, and information about the SA's lifespan.

The ISAKMP main mode sets up a mechanism that's used for future communications. This mode is where agreement on authentication, algorithms, and keys takes place. The main mode requires three back and forth exchanges between sender and receiver. In the first step, the two parties agree on algorithms and hashes for that communication. In the second rally, they exchange public keys using the Diffie-Hellman exchange model and they prove their identities to each other. In the final exchange, the sender and receiver verify those identities.

The aggressive mode actually achieves the same end results as the main mode, only it takes two back and forth exchanges of information instead of the three required in the main mode.

Lastly, there is the quick mode, which can be used after an ISAKMP SA has been created using either the main mode or the aggressive mode to create new material for generating keys. This is also known as a phase two exchange. In the quick mode, all packets are already encrypted, so this step is much simpler than the first two modes.

ISAKMP has some competition in the key exchange and management front in the form of the Simple Key management for Internet Protocol (SKIP). SKIP was developed by Sun Microsystems as an automated key management system. It has been submitted to the IETF as a proposed standard, which has caused some tension in the IPSec working group. Several vendors have shown successful implementations of SKIP, and both SKIP and ISAKMP may be used within IPSec. But to get to a standard way of dealing with key management and to ensure interoperability among IPSec implementations, one of these methods has to go, and right now it looks like SKIP is the unlucky one.

Securely Speaking

Once the IETF gives final sign off on the IPSec suite of protocols, which is expected in early 1998, you can expect the number of products supporting it to increase rapidly. Already there are a number of firewalls and other products that claim to support IPSec, and although many of them may, the immaturity of the standard and interoperability testing is enough to make customers wary for the time being.

Once IPSec finds its way into the security policy of most companies, you can expect to see it used in a variety of applications. It can be used in instances where a network contains information that needs to be kept secure, as well as in cases where only authorized users should be allowed access to network resources.

For example, IPSec can be used when sensitive information is sent over the Internet or when someone from outside the company (a business partner or remote user) wants to come into the network through the Internet.

Perhaps IPSec's most profound impact will be on secure VPNs, which promise to provide a less expensive, yet still secure, method of communication than dedicated private networks. However you look at it, the encryption, authentication, and management capabilities of IPSec make it an encouraging way to extend a private network through the public Internet.

Resources

IPSec Protocol Suite

You can find a white paper on IPSec and related topics at the TimeStep Web site at www.timestep.com/netwsec/index.htm.

To view the IPSec RFCs (1825-1829), go to ftp://nic.mil. Then, click on the RFC/folder and scroll down until you find RFCs 1825, 1826, 1827, 1828, and 1829.

This tutorial, number 115, by Anita Karvé, was originally published in the February 1998 issue of Network Magazine.