14.3 IP SECURITY ARCHITECTURE

Team-Fly

As mentioned in Section 14.2, the IP security architecture comprises an entire suite of security protocols, including, for example, the IPsec protocols (formerly known as IPSP) and the IKE protocol (formerly known as IKMP). Furthermore, the IPsec protocols comprise two subprotocols, namely the Authentication Header (AH) and the Encapsulating Security Payload (ESP). Similarly, the IKE protocol has evolved from two major key management protocol proposals (i.e., ISAKMP and OAKLEY). All of these protocols and subprotocols are introduced and put into perspective later in this chapter.

A high-level overview of the IP security architecture is given in Figure 14.2. In short, an IPsec module is a (hardware or software) module that implements the IPsec architecture and its protocols. The primary goal of an IPsec module is to secure IP traffic that is sent to or received from another IPsec module. What this basically means in terms of security services and mechanisms is specified in a corresponding security association (SA). The aim of the IKE protocol is to establish SAs and the aim of the IPsec protocols is to make use of these SAs. On either side of an SA, the security parameters of that SA (e.g., encryption algorithm and session key) are stored in a security association database (SAD). Each SA and corresponding entry in the SAD is indexed with three values:

A security parameters index (SPI);
An IP destination address;
A security protocol identifier (i.e., AH or ESP).

click to expand
Figure 14.2: High-level overview of the IP security architecture.

As will be explained later, each IPsec-protected packet carries an SPI value that can be used by the recipient to retrieve the correct SA parameters from its SAD. In addition to the SAD, there is a security policy database (SPD) in each IPsec module. The SPD provides detailed specifications of the security services accorded to each packet.

In accordance to this high-level overview, the concept of an SA is at the core of the IP security architecture. An SA specifies the security services and mechanisms that must be implemented and used between two endpoints or IPsec modules. The endpoints, in turn, may be hosts or network security gateways, such as IPsec-enabled routers or application gateways. For example, an SA may require the provision of data confidentiality services through the use of the IPsec ESP protocol (this protocol will be explained later in this chapter). Furthermore, the SA may specifiy the parameters for this protocol, such as the encryption algorithm (e.g., the DES algorithm), the mode of operation (e.g., the CBC mode), and its initialization vector (IV). The SA is a simplex "connection" or "relationship." Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a data stream, then two SAs must be established and maintained. Similarly, to secure bidirectional communications between two hosts or security gateways, two SAs (one in each direction) are required. The term SA bundle refers to a set of SAs through which traffic must be processed to satisfy a specific security policy.

The IPsec architecture allows the user or system administrator to control the granularity at which security services are offered. In the first series of RFCs [7–11], three approaches of how to feed SAs with security parameters and cryptographic keys were distinguished:

Host-oriented keying has all users on one host share the same session key for use on traffic destined for all users on another host.
User-oriented keying lets each user on one host have one or more unique session keys for the traffic destined for another host (such session keys are not shared with other users).
Session-unique keying has a single session key being assigned to a given IP address, upper-layer protocol, and port number triple (in this case, a user's FTP session may use a different key than the same user's Telnet session).

From a security point of view, user-oriented and session-unique keying are superior and therefore preferred. This is due to the fact that in many cases, a single computer system will have at least two suspicious users that do not mutually trust each other. When host-oriented keying is used and mutually suspicious users exist on a system, it is sometimes possible for a user to determine the host-oriented key by cryptanalytical attacks. Once this user has improperly obtained the key in use, he or she can either read another user's encrypted traffic or forge traffic from this particular user. Some possible attacks that follow and take advantage of this line of argumentation can be found in [25, 26]. When user-oriented or session-unique keying is used, certain kinds of attack from one user onto another user's data traffic are simply not possible. Unfortunately, the distinction between the three keying approaches is no longer used in the current protocol specifications of the IETF IPSEC WG. In reality, all we see today is host-oriented keying.

The SPD of an IPsec implementation defines at a high level of abstraction the security requirements for the IP packets that are forwarded or routed. As such, the SPD is established and maintained by a user or system administrator (or by an application operating within constraints established by either of them). Each entry in the SPD defines the traffic to be protected, how to protect it, and with whom the protection is shared. For each IP packet entering or leaving the IPsec implementation, the SPD must be consulted for the possible application of the IPsec security services. More specifically, an SPD entry may define one of the three actions to take upon a traffic match:

Discard: A packet is not left in or out.
Bypass: A packet is left in and out without applying IPsec security services.
Apply: A packet is only left in or out after having applied IPsec security services.

As such, the SPD provides access control enforcement equivalent to a (static) packet filter.

In general, the IPsec protocols (i.e., AH and ESP) are largely independent of the associated SA and key management techniques and protocols, although the techniques and protocols involved do affect some of the security services offered by the protocols. The IPsec protocols and the corresponding key management protocols (including the IKE protocol) are overviewed next.

Team-Fly