| IP Security by William Stallings In 1994, the Internet Architecture Board (IAB) issued a report entitled "Security in the Internet Architecture" (RFC 1636). The report stated the general consensus that the Internet needs more and better security, and it identified key areas for security mechanisms. Among these were the need to secure the network infrastructure from unauthorized monitoring and control of network traffic and the need to secure end-user-to-end-user traffic using authentication and encryption mechanisms. These concerns are fully justified. As confirmation, the 1998 annual report from the Computer Emergency Response Team (CERT) lists over 1,300 reported security incidents affecting nearly 20,000 sites. The most serious types of attacks included IP spoofing, in which intruders create packets with false IP addresses and exploit applications that use authentication based on IP address; and various forms of eavesdropping and packet sniffing, in which attackers read transmitted information, including logon information and database contents. In response to these issues, the IAB included authentication and encryption as necessary security features in the next-generation IP, which has been issued as IPv6. Fortunately, these security capabilities were designed to be usable both with the current IP (IPv4) and IPv6, meaning that vendors can begin offering these features now, and many vendors do now have some IP Security Protocol (IPSec) capability in their products. Applications of IPSec The Internet community has developed application-specific security mechanisms in numerous application areas, including electronic mail (Privacy Enhanced Mail, Pretty Good Privacy [PGP]), network management (Simple Network Management Protocol Version 3 [SNMPv3]), Web access (Secure HTTP, Secure Sockets Layer [SSL]), and others. However, users have some security concerns that cut across protocol layers. For example, an enterprise can run a secure, private TCP/IP network by disallowing links to untrusted sites, encrypting packets that leave the premises, and authenticating packets that enter the premises. By implementing security at the IP level, an organization can ensure secure networking not only for applications that have security mech-anisms but also for the many security-ignorant applications. IPSec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include:
Figure 1: An IP Security Scenario Benefits of IPSec The benefits of IPSec include:
Is IPSec the Right Choice? There are already numerous products that implement IPSec, but it is not necessarily the security solution of choice for a network administrator. Christian Huitema, who at the time of the development of the initial IP-Sec documents was the head of the IAB, reports that the debates over how to provide Internet-based security were among the most heated that he ever observed. One issue concerns whether security is being provided at the right protocol layer. To provide security at the IP level, it is necessary for IPSec to be a part of the network code deployed on all participating platforms, including Windows NT, UNIX, and Macintosh systems. Unless a desired feature is available on all the deployed platforms, a given application may not be able to use that feature. On the other hand, if the application, such as a Web browser/server combination, incorporates the function, the developer can guarantee that the features are available on all platforms for which the application is available. A related point is that many Internet applications are now being released with embedded security features. For example, Netscape and Internet Explorer support SSL, which protects Web traffic. Also, many vendors are planning to support Secure Electronic Transaction (SET), which protects credit-card transactions over the Internet. How-ever, for a virtual private network, a network-level facility is needed, and this is what IPSec provides. The Scope of IPSec IPSec provides three main facilities: an authentication-only function, referred to as Authentication Header (AH), a combined authentication/ encryption function called Encapsulating Security Payload (ESP), and a key exchange function. For virtual private networks, both authentication and encryption are generally desired, because it is important both to (1) assure that unauthorized users do not penetrate the virtual private network and (2) assure that eavesdroppers on the Internet cannot read messages sent over the virtual private network. Because both features are generally desirable, most implementations are likely to use ESP rather than AH. The key exchange function allows for manual exchange of keys as well as an automated scheme. The IPSec specification is quite complex and covers numerous documents. The most important of these, issued in November 1998, are RFCs 2401, 2402, 2406, and 2408. Security Associations A key concept that appears in both the authentication and confidentiality mechanisms for IP is the Security Association (SA). An association is a one-way relationship between a sender and a receiver that affords security services to the traffic carried on it. If a peer relationship is needed, for two-way secure exchange, then two security associations are required. Security services are afforded to an SA for the use of AH or ESP, but not both. A security association is uniquely identified by three parameters:
Hence, in any IP packet, the security association is uniquely identified by the destination address in the IPv4 or IPv6 header and the SPI in the enclosed extension header (AH or ESP). An IPSec implementation includes a security association database that defines the parameters associated with each SA. A security association is defined by the following parameters:
The key management mechanism that is used to distribute keys is cou-pled to the authentication and privacy mechanisms only by way of the security parameters index. Hence, authentication and privacy have been specified independent of any specific key management mechanism. SA Selectors IPSec provides the user with considerable flexibility in the way in which IPSec services are applied to IP traffic. IPSec provides a high degree of granularity in discriminating between traffic that is afforded IPSec protection and traffic that is allowed to bypass IPSec, in the former case relating IP traffic to specific SAs. The means by which IP traffic is related to specific SAs (or no SA in the case of traffic allowed to bypass IPSec) is the nominal Security Policy Database (SPD). In its simplest form, an SPD contains entries, each of which defines a subset of IP traffic and points to an SA for that traffic. In more complex environments, there may be multiple entries that potentially relate to a single SA or multiple SAs associated with a single SPD entry. Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors. In effect, these selectors are used to filter outgo-ing traffic in order to map it into a particular SA. Outbound processing obeys the following general sequence for each IP packet:
The following selectors determine an SPD entry:
Authentication Header The authentication header provides support for data integrity and authentication of IP packets. The data integrity feature ensures that undetected modification to the content of a packet in transit is not possible. The authentication feature enables an end system or network device to authenticate the user or application and filter traffic accordingly; it also prevents the address spoofing attacks observed in today's Internet. The AH also guards against the replay attack described later. Figure 2: IPSec Authentication Header Authentication is based on the use of a Message Authentication Code (MAC); hence the two parties must share a secret key. The authentication header consists of the following fields (Figure 2):
Anti-Replay Service A replay attack is one in which an attacker obtains a copy of an authenticated packet and later transmits it to the intended destination. The receipt of duplicate, authenticated IP packets may disrupt service in some way or may have some other undesired consequence. The Sequence Number field is designed to thwart such attacks. When a new SA is established, the sender initializes a sequence number counter to 0. Each time that a packet is sent on this SA, the sender increments the counter and places the value in the Sequence Number field. Thus, the first value to be used is 1. If anti-replay is enabled (the default), the sender must not allow the sequence number to cycle past 2 32 - 1 back to zero. Otherwise, there would be multiple valid packets with the same sequence number. If the limit of 2 32 - 1 is reached, the sender should terminate this SA, and negotiate a new SA with a new key. Because IP is a connectionless, unreliable service, the protocol does not guarantee that packets will be delivered in order and does not guarantee that all packets will be delivered. Therefore, the IPSec authentication document dictates that the receiver should implement a window of size W, with a default of W = 64. The right edge of the window represents the highest sequence number, N, so far received for a valid packet. For any packet with a sequence number in the range from N - W + 1 to N that has been correctly received (that is, properly authenticated), the corresponding slot in the window is marked. Inbound processing proceeds as follows when a packet is received:
Message Authentication Code The message authentication algorithm is used to calculate a message authentication code, using an algorithm known as HMAC. HMAC takes as input a portion of the message and a secret key and produces a MAC as output. This MAC value is stored in the Authentication Data field of the AH header. The calculation takes place over the entire enclosed TCP segment plus the authentication header. When this IP packet is received at the destination, the same calculation is performed using the same key. If the calculated MAC equals the value of the received MAC, then the packet is assumed to be authentic. The authentication data field is calculated over:
For IPv4, examples of immutable fields are Internet Header Length and Source Address . An example of a mutable but predictable field is the Destination Address (with loose or strict source routing). Examples of mutable fields that are zeroed prior to ICV calculation are the Time to Live (TTL) and Header Checksum fields . Note that both source and destination address fields are protected, so address spoofing is prevented. For IPv6, examples in the base are Version (immutable), Destination Address (mutable but pre-dictable), and Flow Label (mutable and zeroed for calculation). Encapsulating Security Payload The encapsulating security payload provides confidentiality service, including confidentiality of message contents and limited traffic flow confidentiality. As an optional feature, ESP can also provide the same authentication services as AH. Figure 3: IPSec ESP Format Figure3 shows the format of an ESP packet. It contains the following fields:
Encryption and Authentication Algorithms The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service. If the algorithm used to encrypt the payload requires cryptographic synchronization data, such as an Initialization Vector (IV), then this data may be carried explicitly at the beginning of the Payload Data field. If included, an IV is usually not encrypted, although it is often referred to as being part of the ciphertext. The current specification dictates that a compliant implementation must support the Data Encryption Standard (DES). A number of other algorithms have been assigned identifiers and could, therefore, be used for encryption; these include:
It is now well known that DES is inadequate for secure encryption, so it is likely that many future implementations will use triple DES and eventually the Advanced Encryption Standard (AES). As with AH, ESP supports the use of a MAC, using HMAC. Padding
Figure 4 indicates the scope of ESP encryption and authentication in both transport and tunnel modes. Transport and Tunnel Modes Both AH and ESP support two modes of use: transport and tunnel mode. Figure 4: Scope of ESP Encryption and Authentication Transport Mode Transport mode provides protection primarily for upper-layer protocols. That is, transport mode protection extends to the payload of an IP packet. Examples include a TCP or UDP segment, or an Internet Control Message Protocol (ICMP) packet, all of which operate directly above IP in a host protocol stack. For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to the transport layer header (for instance, TCP, UDP, ICMP) and an ESP trailer (Pad-ding, Pad Length, and Next Header fields) is placed after the IP packet. This setup is shown in Figure 4b. If authentication is selected, the ESP Authentication Data field is added after the ESP trailer. The entire transport level segment plus the ESP trailer are encrypted. Authentication covers all of the ciphertext plus the ESP header. Typically, transport mode is used for end-to-end communication between two hosts (for instance, communications between a workstation and a server, or two servers). When a host runs AH or ESP over IPv4, the payload is the data that normally follows the IP header. For IPv6, the payload is the data that normally follows both the IP header and any IPv6 extensions headers that are present, with the possible exception of the destination options header, which may be included in the protection. ESP in transport mode encrypts and optionally authenticates the IP payload but not the IP header. AH in transport mode authenticates the IP payload and selected portions of the IP header. All IPv4 packets have a Next Header field. This field contains a number for the payload protocol, such as 6 for TCP and 17 for UDP. For transport mode, the IP Next Header field is decimal 51 for AH, or 50 for ESP. This tells the receiving machine to interpret the remainder of the packet after the IP header as either AH or ESP. Both the AH and ESP headers also have a Next Header field. As an example, let's examine a Telnet session within an ESP packet in transport mode. The IP header would contain 51 in the Next Header field. In the ESP header, the Next Header field would be 6 for TCP. Within the TCP header, Telnet would be identified as port 23. Transport mode operation may be summarized for ESP as follows:
Tunnel Mode Tunnel mode encapsulates an entire IP packet within an IP packet to ensure that no part of the original packet is changed as it is moved through a network. The entire original, or inner, packet travels through a "tunnel" from one point of an IP network to another; no routers along the way need to examine the inner IP header. For ESP, this is shown in Figure 4c. Because the IP header contains the destination address and possibly source routing directives and hop-by-hop option information, it is not possible simply to transmit the encrypted IP packet prefixed by the ESP header. Intermediate routers would be unable to process such a packet. Therefore, it is necessary to encapsulate the entire block (ESP header plus ciphertext plus Authentication Data, if present) with a new IP header that will contain sufficient information for routing but not for traffic analysis. Tunnel mode is used when one or both ends of an SA is a security gateway, such as a firewall or router that implements IPSec. With tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without implementing IPSec. The unprotected packets generated by such hosts are tunneled through external networks by tunnel mode SAs set up by the IPSec process in the firewall or secure router at the boundary of the local network. Whereas the transport mode is suitable for protecting connections between hosts that support the ESP feature, the tunnel mode is useful in a configuration that includes a firewall or other sort of security gateway that protects a trusted network from external networks. In this latter case, encryption occurs only between an external host and the security gateway or between two security gateways. This setup relieves hosts on the internal network of the processing burden of encryption and simplifies the key distribution task by reducing the number of needed keys. Further, it thwarts traffic analysis based on ultimate destination. Let's use the diagram in Figure 1 as an example of how tunnel mode IP-Sec operates. The following steps occur for transfer of a transport layer segment from the user system to one of the servers on one of the protected LANs.
Figure 5 shows two ways in which the IPSec ESP service can be used. In the upper part of the figure, encryption (and optionally authentication) is provided directly between two hosts. Figure 5b shows how tunnel mode operation can be used to set up a Virtual Private Network (VPN). In this example, an organization has four private networks interconnected across the Internet. Hosts on the internal networks use the Internet for transport of data but do not interact with other Internet based hosts. By terminating the tunnels at the security gateway to each internal network, the configuration allows the hosts to avoid implementing the security capability. The former technique is supported by a transport mode SA, while the latter technique uses a tunnel mode SA. Figure 5: Transport-Mode versus Tunnel-Mode Encryption Key Management The key management portion of IPSec involves the determination and distribution of secret keys. The IPSec Architecture document mandates support for two types of key management:
The default automated key management protocol for IPSec is referred to as Internet Key Exchange (IKE). IKE provides a standardized method for dynamically authenticating IPSec peers, negotiating security services, and generating shared keys. IKE has evolved from many different protocols and can be thought of as having two distinct capabilities. One of these capabilities is based on the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP provides a framework for Internet key management and provides the specific protocol support, including formats, for negotiation of security attributes. ISAKMP by itself does not dictate a specific key exchange algorithm; rather, ISAKMP consists of a set of message types that enable the use of a variety of key exchange algorithms. The actual key exchange mechanism in IKE is derived from Oakley and several other key exchange protocols that had been proposed for IPSec. Key exchange is based on the use of the Diffie Hellman algorithm, but provides added security. In particular, Diffie-Hellman alone does not authenticate the two users that are exchanging keys, making the protocol vulnerable to impersonation. IKE includes mechanisms to authenticate the users. Public Key Certificates An important element of IPSec key management is the use of public key certificates. In essence, a public key certificate is provided by a trusted Certificate Authority (CA) to authenticate a user's public key. The essential elements include:
If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates can be placed in the directory for access by all users. In addition, a user can transmit his or her certificate directly to other users. In either case, once B is in possession of A's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages signed with A's private key are unforgeable. If there is a large community of users, it may not be practical for all users to subscribe to the same CA. Because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key to verify signatures. This public key must be provided to each user in an absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical for there to be many CAs, each of which securely provides its public key to some fraction of the users. In practice, there is not a single CA but rather a hierarchy of CAs. This complicates the problems of key distribution and of trust, but the basic principles are the same. Whither IP Security The driving force for the acceptance and deployment of secure IP is the need for business and government users to connect their private WAN/ LAN infrastructure to the Internet for (1) access to Internet services and (2) use of the Internet as a component of the WAN transport system. Users need to isolate their networks and at the same time send and receive traffic over the Internet. The authentication and privacy mech-anisms of secure IP provide the basis for a security strategy. Because IP security mechanisms have been defined independent of their use with either the current IP or IPv6, deployment of these mechanisms does not depend on deployment of IPv6. Indeed, it is likely that we will see widespread use of secure IP features long before IPv6 becomes popular. Recommended Web Sites
WILLIAM STALLINGS is a consultant, lecturer, and author of over a dozen books on data communications and computer networking. He has a Ph.D. in computer science from M.I.T. His latest book is Local and Metropolitan Area Networks, Sixth Edition (Prentice Hall, 2000). His home in cyberspace is WilliamStallings.com and he can be reached at ws@shore.net |
