| [ LiB ] |   |
Internet Protocol Security
Cisco implements the Internet Protocol Security (IPSec) protocol suite, as detailed in the open standards developed by the Internet Engineering Task Force (IETF), to provide you with security for the transmission of sensitive information over an unprotected network in both Cisco IOS and the PIX's Finesse software.
Cisco's IPSec implementation is based on RFC 2401, Security Architecture for the Internet Protocol, Internet Draft, with Cisco IOS IPSec using RFC 1828, IP Authentication Using Keyed MD5, and RFC 1829, The ESP DES-CBC Transform, for backward compatibility.
IPSec operates at the network layer to provide protection and authentication of IP packets between IPSec peers. IPSec provides you with the following optional network security services. They should be used in accordance with your local security policy:
Data confidentiality Lets the IPSec sender encrypt packets before transmitting them across a network.
Data integrity Lets the IPSec receiver authenticate packets sent by an IPSec sender to ensure that the data has not been altered during transmission.
Data origin authentication Lets the IPSec receiver authenticate the source of the IPSec packets. This service is dependent on the data integrity service.
Anti-replay Lets the IPSec receiver detect and reject replayed packets.
IPSec Architecture
IPSec provides you with the framework used to protect one or more data flows between IPSec peers. IPSec consists of the following two main protocols:
Authentication header (AH) Provides data authentication and optional anti-replay services by being embedded in the data to be protected, a full IP datagram. The AH security protocol is implemented per the latest version of the IP Authentication Header Internet Draft. It also provides backward compatibility with RFC 1828.
Encapsulating Security Payload (ESP) Provides data privacy services, optional data authentication, and anti-replay services by encapsulating the data to be protected. The ESP security protocol is implemented per the latest version of the IP Encapsulating Security Payload Internet Draft. It also provides backward compatibility with RFC 1829.
IPSec implements several standards that are supported by both Cisco IOS and the PIX Firewall:
IPSec Provides the framework of open standards to provide data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer. IPSec also uses the Internet Key Exchange (IKE) protocol to handle negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPSec.
IKE A hybrid protocol that implements Oakley and SKEME key exchanges inside an Internet Security Association and Key Management Protocol (ISAKMP) framework. IKE provides the mechanism to authenticate the IPSec peers, negotiate IPSec security associations (SAs), and establish the IPSec keys.
Message Digest 5 (MD5) A one-way hashing algorithm that produces a 128-bit hash that, along with the Secure Hash Algorithm, is a variation of MD4, which is designed to strengthen the security of this hashing algorithm.
Secure Hash Algorithm (SHA) A one-way hash published by the National Institute of Standards and Technology (NIST). SHA is closely modeled after MD4 and produces a 160-bit digest. Because SHA produces a 160-bit digest, it is more resistant to brute-force attacks than 128-bit hashes, such as MD5, but it can be slower to compute.
Data Encryption Standard (DES) An algorithm used to encrypt packet data. IKE implements the 56-bit DES-CBC with Explicit IV standard. Cipher block chaining (CBC) requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPSec packet. Depending on which software version you are using, you also might be able to use Triple DES (168-bit) encryption.
Diffie-Hellman (D-H) A public-key cryptography protocol designed to allow two parties to establish a shared secret over an unsecured communications channel. IKE uses D-H to establish session keys.
RSA signatures RSA is a public-key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA signatures provide nonrepudiation.
Certification authority (CA) A third-party entity that has the responsibility of issuing and revoking certificates. Each device that has its own certificate and the CA's public key can authenticate every other device within a given CA's domain.
The following sections look at IPSec in more detail.
Authentication Header
The AH, shown in Figure 14-1, provides you with a mechanism to authenticate and verify the integrity of IP datagrams passing between two systems by applying a keyed one-way hash function to the datagram to create a message digest. If the datagram is changed in any way while transiting the network, the receiver detects this when it compares the message digest value it comes up with by performing the same one-way hash function on the datagram sent by the sender. The datagram's authenticity can be guaranteed because the one-way hash mechanism requires the use of a secret shared between the two peers.
Figure 14-1. AH Protocol Packet
AH can require the receiver to set a bit in the header indicating that a packet has been sent to facilitate anti-replay protection. If the replay bit is not used, an unauthorized user might be able to resend the same packet many times.
AH is applied to the entire datagram, with the exception of any IP header fields that might be changed in normal operation while the datagram is in transition from one peer to the other.
ESP
ESP provides confidentiality (encryption), data origin authentication, integrity, optional anti-replay service, and limited traffic flow confidentiality. Figure 14-2 shows an ESP packet.
Figure 14-2. ESP Protocol Packet
ESP provides confidentiality by performing encryption at the IP packet layer through the use of symmetric encryption algorithms. The default algorithm is 56-bit DES, but support for 168-bit 3DES is also allowed. You may select to use confidentiality independent of any other services.
DES Algorithm
DES is used to encrypt and decrypt select packet data. DES does this by using an encryption algorithm, based on a 56-bit key, to turn clear text into cipher text at the sending peer. DES also turns the cipher-text back into clear text by using a decryption algorithm on the remote peer. Both peers need shared secret keys to enable the encryption and decryption of the packets.
Triple DES Algorithm
3DES is an encryption protocol based on 56-bit DES. 3DES is similar to DES in operation, except that each 64-bit block of data is processed three times, with an independent 56-bit key each time. 3DES essentially doubles the encryption strength offered by 56-bit DES.
Advanced Encryption Standard
The Advanced Encryption Standard (AES) feature, developed by NIST, lets you support the new encryption standard, AES, with CBC mode. AES, developed to replace DES, is a privacy transform for IPSec and IKE that provides a larger key size than DES. AES uses a 128-bit default key, a 192-bit key, or a 256-bit key.
IKE
IKE, often called ISAKMP, is a hybrid protocol designed to provide utility services to IPSec. These services include authentication of the IPSec peers, negotiation of IKE and IPSec security associations, and establishment of keys for encryption algorithms used by IPSec.
IKE key negotiation is done in two phases. Phase 1 is used to negotiate the IKE SA, or key, between two IKE peers. This key lets IKE peers communicate securely during Phase 2. Phase 2 is used to negotiate SAs, or keys, for other applications, such as IPSec.
Phase 1 negotiation occurs using one of two modes: main mode or aggressive mode. Main mode protects all information during the negotiation. During main-mode negotiation, the identities of the two peers are hidden. Main mode has one drawback: It requires time to complete its negotiations. Aggressive mode, on the other hand, requires less time to negotiate keys between peers. Although aggressive mode accomplishes the same end result as main mode, it gives up some of the security provided by main-mode negotiation.
IKE Phase 1 can use three methods to authenticate its IPSec peer:
Preshared keys A key value entered into each peer manually (out of band) is used to authenticate the peer.
RSA signatures Uses a digital certificate authenticated by an RSA signature.
RSA encrypted nonces Uses RSA encryption to encrypt a nonce value (a random number generated by the peer) and other values.
IKE also uses a common value used by all authentication methodsthe peer identity (ID). Some examples of the ID are
The peer's IP address
The peer's fully qualified domain name (FQDN)
You can create multiple, prioritized policies on each peer to ensure that at least one policy matches the policy of a remote peer.
During the IKE negotiation process, IKE peers agree on the following parameters:
An encryption algorithm
A hashing algorithm
An authentication method
The lifetime of the SA
Table 14-1 defines each of the five security parameters used to define the IKE policy.
Parameter | Accepted Values | Keyword | Default Value |
|---|---|---|---|
Encryption algorithm | 56-bit DES-CBC 168-bit DES | des 3des | 56-bit DES-CBC 168-bit DES |
Hash algorithm | SHA-1 (HMAC variant) MD5 (HMAC variant) | sha md5 | SHA-1 |
Authentication method | RSA signatures RSA encrypted nonces Preshared keys | rsa-sig rsa-encr pre-share | RSA signatures |
D-H group identifier | 768-bit D-H 1024-bit D-H 1536-bit D-H | 1 2 5 | 768-bit DH |
Any number of seconds | 86400 seconds (one day) |
Tunnel and Transport Modes
AH and ESP can be run in one of two modes: transport or tunnel. Figure 14-3 shows the packet layout of ESP in the two modes as compared to the packet's original format.
Figure 14-3. ESP Encryption and Authentication
Each of these modes is discussed in the following sections.
Transport Mode
Transport mode protects the upper-layer protocols. When used with IPv4, as shown in Figure 14-3 part (a), the ESP header is inserted into the IP packet before the transport layer header. If authentication is used, an ESP Authentication Data field is added immediately following the ESP trailer. Encryption occurs across the entire transport level segment plus the ESP trailer. Authentication is used to authenticate all cipher text plus the ESP header. This format is shown in Figure 14-3 part (b). When used with IPv6, the payload is the data that normally follows both the IP header and any IPv6 extension headers that are present, with the possible exception of the destination options header, which may be included in the protection.
You typically use transport mode for end-to-end communication between two hosts. ESP in transport mode encrypts and optionally authenticates the IP payload but does not touch the IP header. When AH is used in transport mode, it authenticates the IP payload along with select portions of the IP header. All IPv4 packets contain a Next Header field used to identify the payload protocol. This field is set to decimal 50 for ESP and decimal 51 for AH. AH and ESP headers also contain a Next Header field.
Transport-mode operation eliminates the requirement to implement individual mechanisms in each application to provide confidentiality if the application can take advantage of transport mode. It can also be considered efficient, because it adds very little to the IP packet's total length. Be aware that traffic analysis is still possible with transport mode.
Tunnel Mode
Tunnel mode encapsulates the entire IP packet within a second IP packet, ensuring that the original packet cannot be changed during transport through the network. This essentially "tunnels" the entire original, or inner, packet from one peer to the other without any device in between having the need or capability to view the original packet. For ESP, this concept is illustrated in Figure 14-3 part (c). A new IP header with the necessary routing information is appended to the encapsulated block, containing the ESP header plus cipher text and authentication data if present.
Because the new header does not generally contain the original IP source or destination address, tunnel mode is used when one or both ends of an SA are a security gateway, such as a firewall or router that implements IPSec, making traffic analysis impossible. One added benefit of tunnel mode is that any number of hosts behind the IPSec peer may participate in secure communications without having to be modified to implement IPSec. Their unprotected packets are tunneled through external networks by tunnel-mode SAs set up by the IPSec process on the peers transparently to them.
IPSec Transform Sets
A transform set, a combination of individual IPSec transforms, is used to define a specific security policy for your traffic. It is within this transform set that you establish which security protocols and algorithms you will use for your secure communications. You have the option of defining multiple transform sets. However, during the ISAKMP IPSec security association negotiation that occurs in IKE phase 2 quick mode, the peers must agree on a matching transform set to protect a particular data flow.
Transform sets combine the following IPSec factors:
Mechanism for payload authentication AH transform
Mechanism for payload encryption ESP transform
IPSec mode Transport versus tunnel
Transform sets equal a combination of an AH transform plus an ESP transform plus the IPSec mode (either tunnel or transport mode). Table 14-2 lists the acceptable transform sets you may select from.
| [ LiB ] | |