Figure 6.4: AH in tunnel mode.

When ESP is used in tunnel mode, the original IP header is protected because the entire original IP packet is encrypted. When both authentication and encryption are configured, encryption is performed first, before authentication. The reason for this process to take place in this order is that it facilitates rapid detection and rejection of replayed or bogus packets by the receiving node. Prior to decrypting the packet, the receiver can detect the problem and potentially reduce the impact of an attack. Figure 6.5 shows an example of using ESP in tunnel mode.

Figure 6.5: ESP in tunnel mode.

When you want to make sure that certain data from a known and trusted source gets transferred with integrity and the data does not need confidentiality, use the AH protocol. AH protects the upper−layer protocols and the IP header fields that do not change in transit, such as the source and destination addresses. AH cannot protect those fields that change in transit, such as the Type of Service (TOS) field. When the fields are protected, the values cannot be changed without detection, so the IPSec node will reject any altered IP packet. In summary, AH does not protect against someone sniffing the wire and seeing the headers and data. However, because headers and data cannot be changed without the change being detected, changed packets would get rejected.

If data confidentiality is needed, use ESP. ESP will encrypt the upper−layer protocols in transport mode and the entire original IP packet in tunnel mode so that neither is readable. ESP can also provide authentication for the packets. However, when you use ESP in transport mode, the outer IP original header is not protected; in tunnel mode, the new IP header is not protected. You will probably implement tunnel mode more than transport mode during initial IPSec usage. This mode allows a network device, such as a router to act as an IPSec proxy.

Key Management

I'll now discuss Internet Security Association Key Management.

Internet Key Exchange

Internet Key Exchange (IKE) is the facilitator and manager of IPSec−based conversations and is a derivative of Internet Security Association Key Management Protocol/Oakley (ISAKMP/Oakley), specifically for IPSec. IPSec uses the services of IKE to authenticate peers, manage the generation and handling of the keys used by the encryption algorithm, as well as the hashing algorithms between peers. It also negotiates IPSec security associations.

IKE provides three modes for exchanging key information and setting up IKE SAs. The first two modes are Phase 1 exchanges, which are used to set up the initial secure channel; the other mode is the Phase 2 exchange, which negotiates IPSec SAs. The two modes in Phase 1 are main mode and aggressive mode, and the Phase 2 mode is called quick mode. An IKE SA is used to provide a

193

protected pipe for subsequent protected IKE exchanges between the IKE peers and then use Phase 2 quick mode with the IKE SA to negotiate the IPSec SAs.

Main mode has three two−way exchanges between the initiator and receiver. In the first exchange, the algorithms and hashes are agreed upon. The second exchange uses Diffie−Hellman to agree on a shared secret and to pass nonces. (Nonces are random numbers sent to the other party and signed and returned to prove their identity. The third exchange verifies the identity of the other peer.

In aggressive mode, fewer exchanges are done using fewer packets than with main mode. On the first exchange, almost everything is squeezed in—the proposed SA. The receiver sends back everything that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The disadvantage of using the aggressive mode is that both sides have exchanged information before there is a secure channel. Therefore, it is possible to snoop the wire and discover who formed the new SA. However, aggressive mode is faster than main mode.

Quick mode occurs after IKE has established the secure tunnel. Every packet is encrypted using quick mode. Both negotiation of the IPSec SA and derivation of the key material needed by IPSec are accomplished in quick mode. Before IKE will proceed, the potential parties are required to agree upon a way to authenticate themselves to each other. This authentication method is negotiated during the IKE Phase 1 main mode exchange.

Before any traffic can be passed using IPSec, each router/firewall/ host must be able to verify the identity of its peer. This is accomplished by authenticating each peer, and IKE supports multiple authentication methods as part of the Phase 1 exchange. The two entities must agree on a common authentication protocol through a negotiation process. IPSec supports the following negotiation processes:

∙Pre−shared keys

∙Public key cryptography (nonces)

∙Digital signatures

When pre−shared keys are used, identical keys are configured on each host. IKE peers authenticate each other by computing and sending a keyed hash of data that includes the pre−shared key. If the receiving peer is able to create the same hash using its pre−shared key, then it knows that both parties share the same secret key, thus authenticating the other party. Pre−shared keys do not scale well because each IPSec peer must be configured with the key of every other peer with which the router needs to establish a session.

When using public key cryptography, each party generates a pseudo−random number (a nonce) and encrypts it in the other party's public key. The ability for each party to compute a keyed hash containing the other peer's nonce, decrypted with the local private key as well as other publicly and privately available information, authenticates the parties to each other. This system provides for deniable transactions. That is, either side of the exchange can plausibly deny that it took part in the exchange. Currently, only the RSA public key algorithm is supported.

When digital signatures are used, each device digitally signs a set of data and sends it to the other party. This method is similar to public key cryptography, except that it provides nonrepudiation.

Sharing keys does not scale well for a large network. One method that does scale is encapsulation of the public key in a digital certificate authenticated by a Certificate Authority (CA). A CA is a trusted third party who can bind a public key to an identity. In this case, that includes the identity of devices, especially router and firewall devices.

194

In summary, when the IKE negotiation begins, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its configured policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the other peer's received policies. The remote peer checks each of its configured policies in the order of its highest priority first until a match is found.

A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie−Hellman parameter values and when the remote peer's policy specifies a lifetime less than or equal to the lifetime in the policy being compared. If no acceptable match is found, IKE refuses negotiation and IPSec will not be established. If a match is found, IKE will complete negotiation and IPSec security associations will be created

Diffie−Hellman Key Agreement

Diffie−Hellman provides a means for two parties to agree upon a shared secret in such a way that the secret will be unavailable to eavesdroppers. Diffie−Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining your private key and the other party's public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material.

Each peer generates a public key and private key pair. The private key that is generated by each peer is never shared; the public key is calculated from the private key by each peer and the result is exchanged with the other peer. Each peer combines the other peer's public key with its own private key and each peer computes the same shared secret number. The shared secret number is then converted into a shared secret key, which is used for encrypting data using the encryption algorithm specified during the security association setup.

The Diffie−Hellman key agreement has two system parameters, p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p with the following properties: for every number n between 1 and p‘ inclusive, there is a power k, of g k such that n = gk modulus p. The Diffie−Hellman key agreement can be explained further using the following example:

1.The Diffie−Hellman process begins with each host creating a prime number, p (which is larger than 2) and a base number, g, an integer that is smaller than p.

2.Next, the hosts each secretly generate a private number called x, which is less than p 1.

3.The hosts next generate the public keys, y. They are created with the following function:

y = gx % p

4.The two hosts now exchange the public keys (y) and the exchanged numbers are converted into a secret key, z:

z = yx % p

5.The value z can now be used as the key for the IPSec encryption method used to transfer information between the two hosts. Mathematically, the two hosts should have generated the same value for z.

6.This yields the following:

z = (gx % p)x' % p = (gx' % p)x % p

On Cisco devices, Diffie−Hellman can be configured to support one of two different group modes on a per−IKE−policy basis: 768−bit groups or 1024−bit groups. The 1024−bit groups are more challenging to break, but they come with the added expense of being more CPU intensive.

195

Encryption

I'll now discuss encryption.

Data Encryption Standard

IPSec can use either the 56−bit Data Encryption Standard (DES) algorithm or the 168−bit 3DES algorithm for encryption. After two IPSec peers obtain their shared secret key, they can use the key to communicate with each other using the DES encryption algorithm. The 56−bit DES system consists of an algorithm and a key. The key has a length of 64 bits, of which 56 are used as the key. The remaining 8 bits are parity bits used in checking for errors. Even with just 56 bits, there are more than 70 quadrillion possible keys (simply, 2Ž56). The digits in the key must be independently determined to take full advantage of 70 quadrillion possible keys.

The mechanics of DES are relatively simple. DES enciphers data in blocks of 64 bits of binary data. Given a message that needs to be encrypted, one must first pick a 64−bit key and then convert the plaintext into binary form. It takes a string of only 5 bits to describe our alphabet, because 2Ø5Ž32 and the alphabet is 26 letters long. This is relatively easy to do. Now within the blocks or strings of 64 bits, order is very important. The leftmost bit is known as the 1st bit or is in the first position. The rightmost bit is the 64th bit.

The first step in the DES procedure is to change the order within each block. For example, the 52nd bit in the original string becomes the 1st bit in this new block. Bit 40 becomes bit 2 and so forth, as specified by a table. This step is called the initial permutation. Permutation is used in the strict mathematical sense that only order is changed. The results of this initial permutation are broken down into two halves. The first 32 bits become L0. The last 32 bits are called R0. Now the data is subjected to the following transformation 16 times:

Ln = Rn−1 where R0 occurs at n=1

Rn = Ln−1 ( ((Rn−1, Kn) where L0 occurs at n=1

After the first iteration, we are presented with the following:

Rn+1 = Ln ( ((Rn, K0) in essence Rn+1 = Rn−1 ( ((Rn, K0)

Cisco's encryption algorithm incorporates cipher feedback (CFB), which further guarantees the integrity of the data received by using feedback. This is the essence of DES. The key and the message become interwoven and inseparable, which makes it difficult to break apart the cipher text into its constituent parts. This procedure is performed 16 times. The expression Rn = Ln‘ (((Rn+1,

Kn) is simply saying, "Add L, bit by bit in modulo 2, from one iteration ago to the term ((Rn‘, Kn)." This function is determined by R, one iteration ago and Kn, which is based on the key. Kn is, in turn, given by another formula, Kn= KS(n, KEY). Because this algorithm goes through 16 iterations, Kn will be of length 48. The calculation of Kn is another operation in which DES looks in a table. The calculation of the function ((Rn+1,Kn) is likewise simple. First, however, notice that R is of 32−bit length and K is 48 bits long. R is expanded to 48 bits using another table. The resulting R is added to K (using bit−by−bit addition in mod base 2). The result of this addition is broken into eight 6−bit strings. One enters into another table that gives the primitive function Sn. There is one S function for each 6−bit block. The result of entering into these S functions is a 32−bit string. After 16 iterations, the result should be, L16 and R16. These two strings are united where R forms the first 32 bits and L forms the last 32. The 64−bit result is entered into the inverse of the initial permutation function. The result of this last step is cipher text. Decoding is accomplished by simply running the process backwards.

196