Sebery J.Cryptography.An introduction to computer security.1989

18 NETWORK SECURITY

The invention of telephone by Alexander Bell could be regarded as the starting point of the communication revolution. Very soon after this, the global telephone network made the world the \global village" for the rst time in the human history. The telephone network also provided communication infrastructure for computer centres in late 1970s and 1980s. For example, rst electronic funds transfer systems were built using the telephone network.

First works on Computer Networks technology was initiated by the famous ARPANET project that started in the late 1960s. The main focus at that time was the design principles and implementation of communication networks. Unfortunately, the security aspect of communication was not of a major concern, mainly because it was not perceived as a \real problem". The discovery of malicious software such as viruses, worms, or Trojan horses has changed the perception. In particular, computer viruses have become the major security problem, especially for personal computers.

18.1 Internet Protocol Security (IPsec)

The \commercialization" of the Internet in the early 1990s and the growing popularity of World Wide Web applications put the Internet in a completely new light. The computer network infrastructure was seen by some as a new vehicle for conducting trade and commerce in an open manner, reaching millions of people connected to the Internet. These demands brought to the foreground the issues of security, and consequently, the designers of computer networks amended the Internet Protocols so they provided con dentiality and authenticity of messages.

Since the Internet spans the globe, crossing national boundaries, the issues of transborder data ow and national security { from the defence and from the economic point of view { have also come to the foreground. A computer network

592 18 NETWORK SECURITY

Fig. 18.1. A typical computer network

can be regarded as a single \super computer," whose hardware and software resources are distributed over a given geographic area. An especially important component of this super computer is the communication network (Figure 18.1) that connects computers. It is susceptible to illegal activity by unfriendly users. The large physical dimensions of the network make it impossible to protect the network resources by physical security measures [112, 500, 501]. The application of access control methods in the computer network has obvious limitations, for example, it cannot be used to protect information that is being sent through the communication network. The only class of protection methods that can be applied is the class of cryptographic methods. It is worth noting that cryptographic protection does not exclude illegal user activity. Its main bene t is the protection of the computer network against the e ects of such activity.

Recent advances in communications have tried to reconcile two seemingly impossible requirements: unrestricted global access to all communication endpoints and isolation of some parts of the network. The requested isolation is typically temporary and the con guration of the network may uctuate from time to time. This dilemma can be solved by designing two or more computer environments isolated from each other. For example, this solution is often applied by the military. One computer environment is dedicated to military purposes while the other is integrated with the public Internet for unclassi ed infor-

mation. Although quite e ective, this solution is also expensive and in most institutions may not be acceptable.

Firewalls can be deployed to control incoming traÆc and to a protected site (or a local area network). Modern rewalls are fairly sophisticated, combining an extensive range of traÆc control mechanisms. The decision about whether the traÆc is friendly, unwanted, or simply hostile, is made using variety of message identi cation techniques. Typically, rewalls either allow the traÆc to pass or, the traÆc is blocked. Note that the con dentiality aspect is ignored byrewalls.

Therefore, it is possible to distinguish two aspects of networks security:

1.Protection of network nodes { data coming into a network node is carefully examined using access control methods, normally placed in rewalls at network boundaries.

2.Protection of traÆc { data in transit is protected using variety of cryptographic mechanisms.

When rst networks were constructed and suitable standards for Internet communication developed, the security aspect was overlooked. The Internet Engineering Task Force (IETF) is trying to x this by development of new standards for secure Internet communications. For more details about IETF see http://www.ietf.org. In November 1998, the Network Working Group of IETF published their request for comment RFC2401 [276], in which a security architecture for the Internet Protocol (IP) was detailed. The Internet Protocol security (IPsec) is based on the following two protocols:

1.Authentication Header protocol (AH) and

2.Encapsulating Security Payload protocol (ESP)

The AH protocol provides integrity and authentication services, while the ESP protocol delivers mainly con dentiality. These services are implemented on the network layer (see the ISO OSI reference model [501]). Being more speci c, IPsec can be implemented as

{An integral part of the underlying Internet protocol (this is the case for IP version 6 or IPv6).

{An interface between the IP layer and the network driver. This is also called the bump-in-the-stack implementation.

594 18 NETWORK SECURITY

{A separate crypto engine. This is also called the bump-in-the-wire implementation.

18.1.1 Security Associations

A security association (SA) is a unidirectional secure channel that o ers either con dentiality (ESP protocol) or authenticity (AH protocol). If both con dentiality and authenticity are required, two security associations, say, SAESP and SAAU , must be used. The sequence in which these two associations are applied is important. Always the unprotected (clear) message (packet) is rst input to SAESP and later the result is sent to SAAU . In other words, if the clear message is M then M ! SAESP ! SAAU . Note that this order of channels saves time and computing resources when the receiving side deals with corrupted packets. They are discarded after failing the authentication checks (which is typically less expensive than decryption). Note also that to establish a two-way channel with con dentiality and authenticity, one would need four security associations. Each security association is identi ed by the triple: destination IP address, security parameter index and security protocol used (either AH or ESP).

A security association may be applied in either tunnel and transport mode. In the tunnel mode, an SA takes an incoming datagram and encapsulates it in a new datagram with a new header. This mode is used for con dentiality services when the incoming datagram is encrypted and the new header is added to enable the destination point to decrypt it. The transport mode typically leaves the basic structure of a datagram intact with some extra elds attached to it.

In other words, the tunnel mode resembles a postal service in which a post card is put into an envelop at the sender's post oÆce. The destination address on the envelop indicates the post oÆce of the receiver. On the arrival at the receiver's post oÆce, the envelop is removed and the postcard delivered to the destination address. The transport mode can be compared to registered mail service. A post card is time-stamped and a number attached to it. The card still looks the same, but some extra information is attached to it.

18.1.2 Authentication Header Protocol

The AH protocol [277] provides authentication of IP datagrams. The Authentication Header is placed directly after the IP header and is structured as shown

Table 18.1. Authentication Header

in Table 18.1.2. The Next Header eld is 8 bits long and speci es the type of the next payload which follows the AH. The Payload Length (8 bits) eld gives the length of the AH in 32-bit words. The 16-bit Reserved eld is dedicated for future usage. The SPI eld (32 bits) uniquely identi es the security association. The Sequence Number indicates position of the datagram within the stream of packets sent via the security association. This number is used to prevent the reply attack. The Authentication Data contains the Integrity Check Value (ICV) that is used by the receiver to verify the authenticity of the packet.

The ICV is, in fact, a message authentication code (MAC) generated using

1.a keyed hashing based on a private-key cryptosystem (such as DES or LOKI),

2.a collision-free hashing algorithm such as MD5 or SHA-1,

3.a signature based on a public-key cryptosystem.

For point-to-point communication, hashing is recommended while, for multicast communication, signatures are preferred. In general, the ICV is computed for all immutable parts of the packet. In particular, these parts include: IP headerelds, which are immutable, or those whose values can be predicted, the AH header, and the upper level protocol immutable data.

The AH provides also protection against the reply attack. Any packet transmitted for an active SA has a unique (fresh) sequence number. The sequence number inserted into AH is always initialized to zero at the initialization stage of a new SA and incremented by one for each consecutive datagram. The rst packet is assigned 1 as its sequence number. As the sequence number eld contains 32 bits, it is possible to send 232 packets before the sequence number will cycle. To prevent cycles, the SA with sequence number set to zero ( rst full cycle is completed) causes the SA to be closed and a new SA is created.

Table 18.2. Datagram structure for (a) transport and (b) tunnel modes

Security Parameters Index (SPI)

Sequence Number Field

Datagram Payload

Padding

Authentication Data

Table 18.3. ESP Packet Format

It is interesting to note that an SA with the AH protocol only is typically used in the transport mode. If, however, it is used in combination with the ESP protocol, it can be applied in either transport or tunnel mode.

18.1.3 Encapsulating Security Payload Protocol

The ESP protocol is described in [278]. Unlike the AH protocol, the main service delivered by the ESP protocol is con dentiality of transmitted data. An SA based on the ESP protocol can be used in either transport or tunnel mode (Table 18.1.3).

The ESP packet format is given in Table 18.1.3. The rst two elds: SPI and Sequence Number create the ESP header. The padding section together with Pad Length, Next Header and Authentication Data constitute the ESP footer. The SPI (32 bits) uniquely identi es the security association of this datagram. For the rst datagram sent via the SA, the Sequence Number (32 bits) is initialized to 1 and increased by one for each consecutive packet. If

the sequence number over ows (is equal to 232), then this SA is closed and the remaining packets are sent over a new SA. This eld is used for reply prevention. The Datagram Body (also called Payload Data) contains the data carried by the original packet. The Padding is necessary to adjust the length of the encrypted data to be a multiple of 32-bit words. The padding cannot be longer than 255 bytes. The Pad Length (8 bits) speci es the number of bytes in the Paddingeld. The Next Header (8 bits) indicates the type of data in the Datagram Body eld. The Authentication Data eld contains a MAC (or ICV) calculated for the whole datagram (excluding the Authentication Data).

The ESP protocol is designed for private-key encryption (such as DES) as it is typically faster than its public-key counterparts. The authentication is supported by the same algorithms as in the case of the AH protocol.

18.1.4 Internet Key Exchange

The Internet Key Exchange (IKE) is described in [233]. Two parties called Initiator and Responder who wish to establish a common SA (secure channel), call the Internet Security Association Key Management Protocol (ISAKMP). The protocol runs in two stages. In the rst stage, two peers negotiate a common secure channel called an ISAKMP Security Association (ISAKMP SA.) The negotiated attributes include: encryption algorithm, hashing function, authentication method, and the algebraic group for exponentiation (DiÆe-Hellman key agreement). Additionally, a pseudorandom bit generator can be negotiated. An ISAKMP SA is a bidirectional channel and provides both con dentiality and authenticity. Note that a normal SA used to transmit data, is unidirectional and can provide either authentication or con dentiality. In the second stage, the ISAKMP SA is used to exchange key material for an SA.

The key material SKEYID necessary to establish the ISAKMP SA is derived di erently, depending upon an authentication method used. The collection of options is

SKEYID = P BG(NijNr; gxixr ) for signatures,

SKEYID = P BG(H(NijNr); CKYijCKYr) for public-key encryption, SKEYID = P BG(key; NijNr) for pre-shared keys,

where Ni; Nr are payloads of nonce datagrams generated by the initiator and responder, respectively, gxi ; gxr are public keys of the initiator and responder,

598 18 NETWORK SECURITY

respectively, gxixr is the DiÆe-Hellman key (common for both parties), CKYi and CKYr are tokens (also called cookies) for the initiator and responder, respectively. The tokens provide a source address identi cation of two parties. The pair of tokens uniquely identi es the currently valid cryptographic key SKEYID used by the two parties. P BG is an agreed pseudorandom bit generator and H is a hash function. The key SKEYID now is used to generate the three variants

SKEYIDd = P BG(SKEYID; gxixr jCKYijCKYrj0); SKEYIDa = P BG(SKEYID; SKEYIDdjgxixr jCKYijCKYrj1); SKEYIDe = P BG(SKEYID; SKEYIDajgxixr jCKYijCKYrj2);

where SKEYIDd is the key used to derive keys for non-ISAKMP SAs (or simply session keys), and SKEYIDa; SKEYIDe are the keys used by the ISAKMP SA for authentication and con dentiality, respectively. The exchange of information is authenticated using two strings

Hi = P BG(SKEYID; gxi jgxr jCKYijCKYrjSAijIDii);

Hr = P BG(SKEYID; gxr jgxi jCKYrjCKYijSAijIDir);

where SAi is the entire body of the SA payload minus the ISAKMP header, and IDii; IDir are the identi cation payloads for the initiator and responder, respectively. The IKE has two distinct phases: negotiation and establishment. In the rst phase two parties negotiate attributes for the SA and the key material used to establish a common ISAKMP SA.

Negotiation phase of IKE with signatures. Assume that the parties know their true public keys for signature veri cation. Initiator and Responder are two parties who would like to establish a secure channel. The communication between the parties is as follows:

HDR is an ISAKMP header and SA is a negotiation payload. The negotiation payload can contain many options if the SA is sent by Initiator. It must have a single option when the SA is sent by Responder. KE is a key exchange payload with the public exponents used in the DH key agreement. Ni and Nr are nonce payloads generated by the parties. HDR is an ISAKMP header with encrypted payload which follows the header. IDii and IDir are identi cation payloads for the ISAKMP initiator and responder. SIGi and SIGr are the signature payloads for Hi and Hr, respectively. In the rst two steps, parties negotiate security attributes. In steps (3) and (4), parties exchange their nonces and public parameters of the DH key agreement. Now the two parties can calculate the main key SKEYID and its variants SKEYIDd; SKEYIDa; SKEYIDe. The two last variants are used in steps (5) and (6) to provide con dentiality and authentication. The exchange can be compressed by allowing the initiator to send messages in steps (1) and (3) in a one go and the responder to send messages (2) and (4) in one packet. This is the aggressive mode of the IKE protocol.

Negotiation phase of IKE with public-key encryption. This option works under the assumption that the parties know their mutual public keys P Ki and P Kr. The data exchange is given below:

where P Ki and P Kr are the public key of the initiator and responder, respectively, and fmgP K means the cryptogram of message m encrypted using public key P K.

Negotiation phase of IKE with pre-shared key . Assume that the parties share the same secret key. The phase takes the form of the following steps:

Final phase. This phase is used to obtain a key material for non-ISAKMP security associations (or simply session keys). The information exchange is performed via the ISAKMP SA established in the rst phase. In other words, the payloads, except the ISAKMP header, are encrypted. The parties involved in the rst phase may act on behalf of their clients. In this case, the identities of the clients may be used together with the identities of the Initiator and Responder. Typically, the internal security policy determines whether or not this is required. To simplify our considerations we assume that the Initiator and Responder do not have the clients. The exchange of messages is as follows:

where H(1)=P BG(SKEYIDa; MIDjSAjNi), H(2)=P BG(SKEYIDa; MIDjSAjNr), and

H(3)=P BG(SKEYIDa; 0jMIDjSAjNijNr). MID is the message identity from ISAKMP header. If the KE payloads are not exchanged, the key material is

KEYMAT = P BG(SKEYIDd; protocoljSPIjNijNr); otherwise

KEYMAT = P BG(SKEYIDd; gxixr jprotocoljSPIjNijNr):

Note that the keys materials KEYMAT are di erent at both sides as the SPIs used by Initiator and Responder are di erent. If the key material is too short, the IKE protocol expends it by applying the following iterative procedure

K1 = P BG(SKEYIDd;protocoljSPIjNijNr ); : : :

Ki+1 = P BG(SKEYIDd; KijprotocoljSPIjNijNr); : : :