Components of Security Models

CH05-P374463.indd 115

116 CHAPTER 5 Concepts in IP Security

Firewalls are responsible for applying access control. They fi lter the IP pack- ets that they forward based on many properties, including source and destination IP address, payload protocol, transport port number, and any other quality that the security manager deems appropriate. The simplest confi gurations are called

IP Access Lists and are lists of remote IP addresses that are allowed to source mes- sages that will be passed into the private network through the fi rewall. Other common fi lters limit access only to designated hosts (destination IP addresses) and even then restrict incoming packets to those that carry a particular protocol (such as TCP) and target specifi c port numbers (such as port 80 for web access). Packets that are not allowed through are simply discarded—no special error mes- sage is returned because this would surely help a hacker discover a way to pen- etrate the security.

Filters applied at fi rewalls can be inclusive or exclusive (or both)—that is, they may be a list of packets that is allowed through, or a list of packets that will be denied access. There are advantages and disadvantages to each approach and a trade-off must be made between the cost of misconfi gurations that allow inadver- tent access and those that block legitimate use. The latter can normally be fi xed quite simply and (provided that the security manager does not panic or overreact when responding to an annoyed user) it is usually considered better to build up a profi le of users and packet types that are allowed access than to try to list each of the sources that is not allowed.

A further fi rewall model inserts an additional computer between the fi rewall router and the gateway router. This computer serves as an application gateway, and all connections from one side of the fi rewall to the other are terminated and regen- erated at this node, as shown in Figure 5.2 . The application gateway can be made additionally secure by applying access control on each side so that the only con- nections allowed are between the private network and the application gateway, and between the application gateway and the Internet. The application gateway maps connection requests onto connections to real hosts within the private network, hid- ing those nodes from the outside world—a feature similar to that supplied by HTTP

Private Network Internet Gateway/Firewall Router Firewall Router Application Gateway FIGURE 5.2

Application security may be enhanced by the use of an application gateway positioned between two fi rewall routers.

CH05-P374463.indd 116

117

proxies. Similarly, such gateways may map application protocols or even network protocols, providing access to the Internet for proprietary or nonstandard networks. Firewall security may actually be condensed to run on a single box so that an application gateway may be combined with a fi rewall router, or a home computer may run simple access control on its dial-up connection to the Internet.

Firewalls are a popular security solution because they are a simple concept and they provide a single point of security management. This allows the responsibility for security to be placed in the hands of a single person who has only to man- age and confi gure a single computer. Such an approach is also cheap to imple- ment, requiring the addition of only one network element and providing security through a simple software solution. On the other hand, this form of packet fi ltering may cause an undesirable bottleneck in the path of legitimate data traffi c since all packets must pass through the one point of connection and each must be subject to a series of checks against the confi gured rules.

In the end, however, access control is of only limited effi cacy. Malicious users may impersonate others either by stealing their user names and passwords, or by changing their IP addresses to get through the fi rewall. The very nature of the fi rewall includes the crack through which an intrusion may occur.

This means that full security must be achieved through more complex tech- niques described in the sections that follow.

fi re wall n : a wall constructed to prevent the spread of fi re .

5.3.2 Authentication

Authentication serves two purposes: it validates that the user or the sender of a message is who he or she claims to be, and it ensures that the message received is genuine and has not been tampered with. At an application level, authentica- tion is usually provided through a user ID and password exchange building on the application access control mechanisms already described. Application-level authentication is most often applied to transactions or sessions (that is, at a rela- tively high level), although individual components of transactions may be authen- ticated through the use of digital signatures.

At a per-message level in routing, signaling, and transport protocols, or in IP itself, authentication usually takes the form of a validation process applied to parts or the whole of the message being transported. The sender runs an algorithm over the whole of the message (usually in conjunction with a secret string called a key ) and includes the output from the algorithm with the message that is sent. The receiver runs the same algorithm over the message using the same key and checks that its result is the same as the one it received. Any attempt by a third party to modify the message will cause the receiver’s answer to differ from the one in the message. Since the key is not transmitted, and since it is known only to the sender and the receiver, the attacker cannot patch up the message to defeat the authenti- cation process.

5.3 Components of Security Models

CH05-P374463.indd 117

118 CHAPTER 5 Concepts in IP Security

The use of sequence numbers within the protocol messages protected by an authentication scheme helps defeat replay attacks because a replayed message with an incremented sequence number will fail the authentication test, and a replayed message without a change to the sequence number will be rejected by the protocol.

5.3.3 Encryption

Authentication is all very well, but it does not protect the privacy of data that is sent through a public network or over public connections. This data is exposed and may easily be read by anyone using reasonably simple technology. The obvi- ous risks to passwords, fi nancial details, and confi dential information require the use of other techniques to hide or encrypt the data that is sent.

Encryption techniques on the Internet are not really that dissimilar to those used in all of the best spy movies. Some formula is applied to the source data to convert it into a stream of apparently meaningless characters. This information can then be safely transmitted across the Internet to the recipient, who applies another formula to decrypt the message and discover the data.

Successful encryption algorithms rely on the fact that someone who intercepts a message cannot readily decrypt it. The fi rst approach to this technique is to keep the encryption and decryption formulae secret—if the algorithms are good, no one will be able to interpret the messages that are exchanged. The problem with this technique is that the algorithm must be well known for the security process to have wide application, which defeats its effi cacy as a primary security measure.

The solution is to enhance the encryption algorithms with keys. These keys provide additional input to the encryption and decryption processes, making them unique even when the algorithms are well known. The keys are private to the sender and receiver of the messages.

Encryption may be applied at any level within the network. In many cases, applications or users encrypt all or part of the data they want to send—this is, for example, how credit card details are exchanged during commercial transactions on the World Wide Web. In other circumstances, the transport or network pro- tocols are asked to provide encryption on behalf of the applications—the most widespread encryption and authentication technique at the network layer is pro- vided by IPsec, discussed in the next section.

Authentication and encryption may be applied independently or in combination.

5.4 IPsec

IP security (IPsec) defi nes a standard way in which IP datagrams may be authen- ticated or encrypted when they are exchanged between two nodes. The security architecture for IPsec is described in RFC 2401, and RFC 3457 explains some com- mon scenarios in which IPsec may be used. The protocol extensions for IPsec

CH05-P374463.indd 118

119

are defi ned in RFC 2402 (authentication) and RFC 2406 (encryption) and are explained in the sections that follow.

Secure packet exchanges using IPsec occur between a pair of cooperating nodes that establish a Security Association (SA). The SA essentially defi nes the type of security (authentication and/or encryption), the algorithms, and the keys to be applied to all IP packets exchanged between the nodes. As a point of preci- sion, SAs are actually unidirectional, but it would be normal to instantiate them in both directions using the same characteristics with the possible exception of the keys, which might be different for each direction.

IPsec may be deployed end-to-end between host computers or across the net- work by proxy security servers on behalf of the hosts. That is, the SA may extend from data source to data sink, or may cover only part of the path between the two end points.

5.4.1 Choosing between End-to-End and Proxy Security

Figure 5.3 shows the difference between end-to-end security and the proxy

model. In the end-to-end case, the Security Association extends from the source to the destination and packets are fully encrypted or authenticated along the whole length of their path. This is the maximally secure solution.

For proxy security, a node part-way along the data path (a proxy) is responsible for applying IPsec to the IP packets and transferring them to another proxy that validates or decrypts the packets before passing them on to the fi nal destination.

IP Network Source Destination IP Network End-to-End Security Proxy Security FIGURE 5.3

IPsec may be applied in an end-to-end model or across only part of the network using proxy security.

5.4 IPsec

CH05-P374463.indd 119

120 CHAPTER 5 Concepts in IP Security

Proxy security has the obvious drawback that the packets are exposed for part of their path. However, it has many positive points that make it useful and popular. First, it reduces the implementation complexity at the end points—in the proxy model, one proxy may serve multiple end points, allowing the security code to be concentrated just on the proxies. This process extends to allow a single SA to carry traffi c belonging to multiple data streams. This is possible if several hosts served by one proxy want to communicate with other hosts served by a second proxy. In this mode of operation, the IP packets from the data streams are grouped together and treated to the same security measures and forwarded to the same remote proxy as if down a tunnel.

A fi nal advantage of the proxy model is that, in IPsec, it hides the source and destination IP information as packets traverse the core network. As will be seen in later sections, when packets enter the IPsec tunnel they are completely encap- sulated in a new IP packet that fl ows between proxies—this increases the secu- rity by not exposing the end points of the data fl ows.

End-to-end security is used when individual remote nodes connect into net- works (for example, when dialing in through a public network). Proxy security is used when using a public network to connect together networks belonging to the same company to form a virtual private network (VPN).

5.4.2 Authentication

As described in Section 5.3.2, authentication is achieved by processing the mes- sage with a key. This is illustrated in Figure 5.4 . In IPsec the IP header, data pay- load, and a key are processed through an authentication algorithm to produce

authentication data. This authentication data is placed in an Authentication

IP Header Data Key

IP Header Authentication_Header Data

FIGURE 5.4

IPsec authentication is used to verify that the sender of a message is legitimate and that the message has not been tampered with.

CH05-P374463.indd 120

121

Header inserted between the IP header and the payload. The Authentication Header is shown in Figure 5.5 .

The hashing algorithm is performed on the whole IP packet to be transmit- ted—that is, the IP header and the data. The value generated by the hashing pro- cess is placed in the Authentication Data fi eld of the Authentication Header and transmitted to the destination. At the destination, the algorithm is performed again on the IP header and the data (but not the Authentication Header) using the same key. The result is compared with the transmitted authentication data to ver- ify that no modifi cation of the packet has occurred. This process and the format of the IPsec Authentication Header are described in RFC 2402.

Any authentication algorithm may be used, and plenty are defi ned. IPsec places a requirement on implementations that at least the Message Digest Five (MD5) algorithm is supported (see Section 5.7.1). It is (obviously) a requirement that both the sender and the receiver know which authentication algorithm is in use, and the values of the keys. IPsec does not discuss how this information is exchanged or confi gured, but Section 5.8 describes some possibilities.

One issue should be immediately apparent: some of the values in the IP header may legitimately be modifi ed as the packet traverses the network and this will invalidate the authentication process. To avoid this problem the hashing algo- rithm is applied to the IP packet with certain key fi elds (TTL, ToS, checksum, and fl ags) set to zero. Further, the next protocol fi eld is modifi ed by the insertion of the Authentication Header; it is set to 51 (0x33) to indicate that an Authentication Header is present. The hashing algorithm is applied to the IP packet at the source before the insertion of the Authentication Header, and at the destination it is performed after the removal of the Authentication Header. The Authentication Header, shown in Figure 5.5 , carries the payload protocol for restoration into the IP header, and indicates its own length for ease of removal.

One last observation should be made about the insertion of an Authentication Header. The presence of the header may cause the IP packet size to exceed the

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

0 1 2 3

Authentication Header Length

Next Protocol Reserved

Sequence Number Security Parameter Index

Authentication Data

FIGURE 5.5

The IPsec Authentication Header is inserted into IP packets to carry authentication information.

5.4 IPsec

CH05-P374463.indd 121

122 CHAPTER 5 Concepts in IP Security

MTU size for the link into the network. If fragmentation is not allowed, the size of source data packets must be modifi ed before authentication can be used because, otherwise, the packet may be fragmented. Note that fragmentation at the source node is no different from fragmentation within the network—it is performed on the whole IPsec packet, including the Authentication Header (there is no ques- tion of one Authentication Header per fragment) and so the fragments must be reassembled at the destination before they can be authenticated.

The Authentication Header (shown in Figure 5.5 ) includes a Security Parameter Index (SPI) that is used to identify the Security Association that manages this packet. Given a source and destination address pairing, the SPI uniquely identi- fi es the security context, telling the receiver which algorithms and keys to apply. The SPI should be generated randomly to reduce predictability and to limit the chances of a restarting node accidentally reusing an old Security Association. The SPI values 0 through 255 are reserved. A Sequence Number is designed to help prevent denial of service attacks in which malicious parties capture and replay packets or sequences of packets. The sequence number may help the destination node determine that received packets are duplicates or are out of order and dis- card them without further processing. Finally, the Authentication Header contains the output of the hashing algorithm in a fi eld that will vary in length depending on the algorithm in use.

Authentication can be applied in the end-to-end model or using proxies: in each case the format of the message is the same.

5.4.3 Authentication and Encryption

When data is encrypted an encryption algorithm is fed with a stream of data and an encryption key. The output is a new stream of data that may be longer than the original data. When IPsec encryption is used in end-to-end mode, the data part of the source IP packet is encrypted and transported with the original IP header.

The encrypted data is named the Encapsulated Security Payload (ESP) and is

placed between an ESP header and trailer, as shown in Figure 5.6 .

In proxy IPsec encryption the whole source IP packet (header and data) is encrypted as shown in Figure 5.7 . A new packet is built with a new IP header that handles the passage down the tunnel from one proxy to the other. The data of this new packet is the encrypted source packet encapsulated between an ESP header and trailer.

Many encryption algorithms exist, and they operate on keys of varying com- plexity. A massive industry has grown up around the confl icting desires of pri- vacy and transparency, conspiracy and law enforcement. Suddenly, mathematicians who devise these procedures discover that they can be popular if they work in this fi eld. IPsec mandates that implementations must at least support the Data Encryption Standard (DES). This algorithm is discussed in Section 5.7.

The IPsec encryption process is described in RFC 2406. The ESP packet format shown in Figure 5.8 starts off simply enough. After the normal IP header, which

CH05-P374463.indd 122

123

carries a next protocol value of 50 (0x32) to indicate that an ESP header is pres- ent, the ESP header begins with an SPI and Sequence Number that are used in the same way as they are in the authentication process described in the previous sec- tion. From here on, however, the packet seems to be a bit of a mess! It is easiest to