The Internet Protocol Security Protocol

IPSec was created simply to secure network packets when being transported for newer versions of the Internet Protocol such as Ipv4 and Ipv6. For more IPSec information, take a look at the www.ietf.org/rfc/rfc2409.txt site. IPSec makes up two main protocols, and at least two supporting protocols. The two main protocols are the Authentication Header (AH), found at www.ietf.org/rfc/rfc2402.txt , and Encapsulating Security Payload (ESP), at www.ietf.org/rfc/rfc2406.txt . In addition, there are two supporting protocols to exchange keys securely: the Internet Security Association Key Management Protocol (ISAKMP), found at www.ietf.org/rfc/rfc2408.txt , and the Internet Key Exchange (IKE), at www.ietf.org/rfc/rfc2409.txt .

Both AH and ESP support authentication, message integrity, and reply protection. ESP provides extra functionality for data confidentiality to protect the data in the network packet. Shared keys are needed to provide the authentication and encryption services and the capability to transmit the keys securely. The ISAKMP defines the communication process, the security level, and how the AH and ESP use the key exchange. The ISAKMP doesn't define the key exchange algorithms like DH and RSA; that definition is the purpose of the IKE. The IKE uses the ISAKMP to provide the keys to the AH and ESP. The relationships of the IPSec protocols are illustrated in Figure 6-1.

Figure 6-1: The IPSec protocol relationships

Figure 6-1 shows that the AH and ESP protocols provide some of the same functionality. Not only can they support some of the same functionality, but they also can be used in parallel. The ESP and AH headers can be used to add security in the network packet.

How the headers are defined determines some of the security features. The ESP header must be formatted before the data that it encrypts. The IPSec is a security mechanism defined for the Internet Protocol (IP). The ESP and AH headers are encapsulated by the IP header. The AH is merely a header and doesn't include the trailer. All the fields in the AH header are clear text.

The transport and tunnel modes

Another factor that defines the encapsulation of the headers is the operating mode of the IPSec. There are two operating modes of IPSec, the transport mode and the tunnel mode .

The transport mode is used to protect the next levels of encapsulation beyond IP such as the Transmission Control Protocol (TCP) and UDP. AH and ESP intercept the packets between the transport and network layers and provide the selected security.

The tunnel mode is used to protect the entire network packet. In tunnel mode, IPSec adds an IPSec header, called the inner header. The security device also adds an additional IPSec header - called the outer header . Nested tunnels, where you tunnel a tunneled packet, are also possible in IPSec. Listing 6-1 illustrates the operating modes of IPSec.

Listing 6-1: The IPSec operation modes

 An example of the transport mode header is  [IP Header [IPSec Header [TCP Header [Data]]]] An example of the tunnel mode header is  [IP Header [IPSec Header [IP Header [TCP Header [Data]]]]]

There are four possible combinations of modes: AH in transport mode, AH in tunnel mode, ESP in transport mode, ESP in tunnel mode. The AH and ESP header do not change between modes; the difference is basically whether the IP packet or the IP payload is being protected.

The AH and ESP headers are formatted differently based on the type of mode, either a tunnel mode or a transport mode. One of the biggest differences between the ESP and AH headers is that the ESP header requires an associated trailer. The data between the ESP header and the ESP trailer is the data encrypted to provide confidentiality by the ESP. The encrypted data could be an AH header that performs authentication by another host or router.

Tip	The AH in tunnel mode protects the same data as the AH in transport mode and, therefore, is not used in practice.

Listing 6-1 shows examples of the network packets in the transport and tunneling mode. The tunneling mode contains extra IP headers that are added on by network devices like routers and hosts to provide the security services. For each tunnel, an extra IP header is added. A tunnel is a network connection between two intermediate endpoints that are embedded in two larger endpoints. An example of a tunnel is shown in Figure 6-2.

Figure 6-2: An example of a tunnel

In Figure 6-2, the tunnel specified in the inner IP header would be the source address of router R1 and the destination address of R2. Tunnels are used when the originator didn't initialize the security such as in the Virtual Private Networks (VPNs) and as a means to provide intermediate security that is different.

Tip	You may be wondering what the difference is between SSL and IPSec. SSL at the application layer. IPSec is a security mechanism of IP v 6.0 at the network or transport layer that your hardware must be aware of. Some applications may run on top of IPSec and not know it.

Security Associations

To establish any secure channel between two hosts or any routers, a Security Association (SA) must be created. There are many different types of SAs based on protocols. The IPSec SA contains the security association that uses ESP and AH protocols. The IPSec SA is the security parameters, policies, and key material between two peers. The SA is the security contract between the two peers. The SAs are maintained in a database of SA entries called the SA Database (SADB). A table in the SADB could be created for each protocol and each direction that the SA uses.

The ISAKMP SA initializes the IKE key exchange and is needed to provide a secure channel for doing the key exchange. The ISAKMP SA creates the IKE SA. The IKE SA creates the IPSec SA. The IKE SA is needed to pass the security parameters in a secure channel to start the IPSec SA.

The IPSec SA is unidirectional, meaning that SA only works in one direction to a host. For a multiplex or bidirectional connection traveling both directions to a host, two SA instances are needed. For an example, see Figure 6-3.

Figure 6-3: The SA example

Figure 6-3 shows that two SAs are needed for the IPSec SA (SA ₁ and SA ₂ ) to establish messages in both directions to the hosts. SA associates the security services with the key, associates which network packets require security, and associates the security between the two peers. Each SA is uniquely identified by the Security Parameter Index (SPI); the index is in the IPSec protocol headers ESP and AH. The SPI is used to uniquely identify the SA and to determine which SA to communicate with.

Figure 6-3 also shows the ESP header and AH header in a tunnel mode. The IPSec network packet contains one tunnel because it contains one extra IP header. The IP header and AH header in this example are encrypted to ensure confidentiality. The inner IP header could be used between two routers in the middle of the two hosts to establish a tunnel. The outer IP header was built by the outbound host and is aware only of the source host, Host A, and the destination host, Host B.

The ISAKMP negotiates the key materials and cryptographic parameters that include the SPI for the IPSec SA. The IPSec SA contains the collection of the key materials and cryptographic material that was negotiated by the ISAKMP. The AH and ESP use the material supplied by the SA to establish authentication and a secure connection. The ISAKMP SA is used by the IKE to perform the key exchange.

Determining the security level

Before an SA is created, the IPSec must determine the level of security needed, if any. The IPSec determines the level of security and the security parameters based on the policy. The policy defines the security requirements for the IP packet. The policy is checked during the creation of an outbound packet and confirmed during the inbound packet to ensure that the security matches from host to host. The policies are stored in the Security Policy Database (SPD). The SA might already be created and, in that case, the SPD simply points toward the existing SA. If the SA wasn't created, a new SA must be instantiated . The IKE establishes the key exchange for the SA. The policy from the SPD determines the security of the packet.

The IKE protocol is a request-reply protocol. The request is called the initiator and the reply is called the responder . The initiator constructs an SA with the key exchanges specified by the policy. The key exchange started by the initiator must be exchanged with the responder. The IKE always uses the Diffie-Hellman (DH) key exchange. The key exchange depends on the mode specified by the policy for the IKE.

Cross-Reference

See Chapter 4 for a discussion of the Diffie-Hellman key exchange.

The two phases of the key exchange

The key exchange has two phases. Phase 1 has two modes that can be used: the Main mode and Aggressive mode, described later in this chapter. Phase 2 consists of one mode called the Quick mode for exchanging key material and parameters to other services beyond the SA key exchange.

The IKE uses the ISAKMP SA to communicate between the peers. The ISAKMP SA is bidirectional, which implements the request-reply created in phase 1. After phase 1, either peer can initiate the phase 2 Quick mode. Phase 1 establishes a secure channel between the two peers. Phase 2 extends the secure channel to negotiate more security services beyond the IKE, such as the rest of the protocols for IPSec.

The IKE uses ISAKMP to establish the SA. ISAKMP defines five different types of exchanges. Each of these exchanges has different goals, and they do not strictly belong to either phase 1 or 2 - rather, they are used for their specific goals.

The base exchange minimizes the number of exchanges by allowing the key exchange and authentication information to be transmitted together. It uses four messages: the first two to provide cookies and establish an SA, the last two to exchange the key material and user identifications.
The identity protection exchange expands the base exchange to protect the identity of the user. It uses four messages to establish the SA, the key exchange, and reply protection. Finally, the parties use two more messages to establish encrypted authentication to hide the identity of the peers.
The authentication only exchange authenticates the peers using three messages and does not include a key exchange.
The aggressive exchange minimizes the number of exchanges, but it does not povide identity protection.
The informational exchange is a one-way communication that allows peers to send status and error messages. They are not acknowledged nor guaranteed to arrive .

The cookies are part of the ISAKMP header. The ISAKMP header contains the initiator cookie, the responder cookie, next payload, version, exchange type, flags, message ID, and total message length. Each cookie is unique to the remote peer and to the exchange in which it is defined. The cookies keep track of the state of the information and the ISAKMP exchange of information in progress. The cookies are exchanged in the ISAKMP header and provide some connection integrity. The first message sends a cookie to the responder from the initiator and the responder replies with a cookie. The cookies change states based on the message exchange and the current SA. For each message exchange, the protocol advances a state. After the state is advanced, the exchanges cannot rollback to the previous state.

The ISAKMP SA initializes as a connection pipe, but a policy must define and associate with both peers so that they can understand what the requirements of the ISAKMP SA are. The policy is exchanged. The policy defines the different parameters and payloads allowed in the ISAKMP SA.

The IKE defines the key exchange by executing the ISAKMP. The end result of the IKE is the IPSec SA. After the ISAKMP SA is established, the IKE starts phase 1. IKE first defines the phase 1 attributes of the SA that exchange the keys. Other security attributes, including phase 2, are defined using the Domain of Interpretation (DOI). For more information take a look at www.ietf.org/rfc/rfc2407.txt . Phase 1 must be done first to establish a secure channel to pass keys. The attributes, such as encryption and one-way hash algorithms, are referred to as a protection suite . The protection suite is agreed upon through the ISAKMP SA. After the ISAKMP SA has agreed on the parameters, the IKE SA must be created at the end of phase 1.

Phase 1 Two modes: Main and Aggressive

As previously mentioned, there are two modes that can be used to create the IKE SA, Main mode and Aggressive mode. The Aggressive mode is the fastest in execution. The Main mode uses all of the capabilities of the ISAKMP exchanges to ensure that the key exchange is secure and provides identity protection. Identity protection is important when the peers want to hide their identities and authentication is the key exchange algorithm. Authentication is important to avoid man-in-the-middle attacks. The Main mode uses six message exchanges. The first two messages are used to negotiate the policy for the IKE SA. The next two messages are used to exchange the DH key. The final two messages are used to authenticate the DH key exchange.

Cross-Reference

See Chapter 4 for a discussion of the man-in-the-middle attack.

The Aggressive mode uses half the message exchanges that the Main mode does, which makes the key exchange faster but less secure. The first two messages are used to negotiate policy, exchange the DH keys, and authenticate the responder at the same time. The last message is used to authenticate the initiator. Because there are fewer messages being exchanged and more information in each packet, it is more prone to attacks.

The Quick mode, phase 2 only mode

After the IKE SA is generated, the next step is to generate the IPSec SAs for the ESP and AH. The IPSec SA is established through the phase 2 Quick mode exchange. The Quick mode exchange is used in the now secure IKE SA with a single key exchange. The Quick mode exchanges the security parameters and a new key set for the IPSec SA. The IKE SA protects the exchanges by encryption, authentication, and data integrity. The Quick mode is quick because it generates IPSec SAs simultaneously , and is not a complete exchange because it uses material from the IKE SA done in phase 1. After the Quick mode, the IPSec SA is ready to be used by the AH and ESP protocols.

Upon completion of a Quick mode, the previous IKE SA returns to a waiting state for further communication from the peer. The IKE SA stays active until it expires or is deleted. After the IPSec SA has been created, the AH and ESP can be used for securing the channel.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Qshell for iSeries

High-Speed Signal Propagation[c] Advanced Black Magic

Developing Tablet PC Applications (Charles River Media Programming)

What is Lean Six Sigma

HTI+ Home Technology Integrator & CEDIA Installer I All-In-One Exam Guide

Cultural Imperative: Global Trends in the 21st Century