Part I of this technical report covered Network-Layer Encryption background information and basic Network-Layer Encryption configuration. This part of the document covers IP Security (IPSec) and Internet Security Association and Key Management Protocol (ISAKMP).

IPSec was introduced in Cisco IOS® Software Release 11.3T. It provides a mechanism for secure data transmission and consists of ISAKMP/Oakley and IPSec.

The information in this document is based on the software and hardware versions:

Cisco IOS Software Release 11.3(T) and later

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Authentication: The property of knowing that the data received is actually sent by the claimed sender.

Confidentiality: The property of communicating so that the intended recipients know what is being sent but unintended parties cannot determine what is sent.

Data Encryption Standard (DES): The DES utilizes a symmetric key method, also known as a secret key method. This means that if a block of data is encrypted with the key, the encrypted block must be decrypted with the same key, so both the encryptor and the decrypter must use the same key. Even though the encryption method is known and well published, the best publicly known attack method is through brute force. Keys must be tested against the encrypted blocks to see if they can correctly resolve them. As processors become more powerful, the natural life of DES is nearing its end. For instance, a coordinated effort using spare processing power from thousands of computers across the Internet is able to find the 56-bit key to a DES encoded message in 21 days.

DES is validated every five years by the US National Security Agency (NSA) for meeting the purposes of the US Government. The current approval expires in 1998 and the NSA has indicated that they will not re-certify DES. Moving beyond DES, there are other encryption algorithms which also do not have any known weaknesses other than brute force attacks. For additional information, see DES FIPS 46-2 by the National Institute of Standards and Technology (NIST).

Decryption: The reverse application of an encryption algorithm to encrypted data, thereby restoring that data to its original, unencrypted state.

DSS and Digital Signature Algorithm (DSA): The DSA was published by the NIST in the Digital Signature Standard (DSS), which is a part of the U.S. government's Capstone project. DSS was selected by NIST, in cooperation with the NSA, to be the digital authentication standard of the U.S. government. The standard was issued on May 19, 1994.

Encryption: The application of a specific algorithm to data so as to alter the appearance of the data making it incomprehensible to those who are not authorized to see the information.

Integrity: The property of ensuring that data is transmitted from source to destination without undetected alteration.

Non-repudiation: The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data.

Public Key Cryptography: Traditional cryptography is based on the sender and receiver of a message knowing and using the same secret key. The sender uses the secret key to encrypt the message, and the receiver uses the same secret key to decrypt the message. This method is known as "secret-key" or "symmetric cryptography." The main issue is getting the sender and receiver to agree on the secret key without anyone else finding out. If they are in separate physical locations, they must trust a courier, or a phone system, or some other transmission medium to prevent the disclosure of the secret key being communicated. Anyone who overhears or intercepts the key in transit can later read, modify, and forge all messages encrypted or authenticated using that key. The generation, transmission, and storage of keys is called key management; all cryptosystems must deal with key management issues. Because all keys in a secret-key cryptosystem must remain secret, secret-key cryptography often has difficulty providing secure key management, especially in open systems with a large number of users.

The concept of public-key cryptography was introduced in 1976 by Whitfield Diffie and Martin Hellman in order to solve the key management problem. In their concept, each person gets a pair of keys, one called the public key and the other called the private key. Each person's public key is published while the private key is kept secret. The need for the sender and receiver to share secret information is eliminated and all communications involve only public keys, and no private key is ever transmitted or shared. No longer is it necessary to trust some communications channel to be secure against eavesdropping or betrayal. The only requirement is that public keys are associated with their users in a trusted (authenticated) manner (for instance, in a trusted directory). Anyone can send a confidential message simply by using public information, but the message can only be decrypted with a private key, which is in the sole possession of the intended recipient. Furthermore, public-key cryptography can be used not only for privacy (encryption), but for authentication (digital signatures) as well.

Public Key Digital Signatures: To sign a message, a person performs a computation involving both their private key and the message itself. The output is called the digital signature and is attached to the message, which is then sent. A second person verifies the signature by performing a computation involving the message, the purported signature, and the first person's public key. If the result properly holds in a simple mathematical relation, the signature is verified as being genuine. Otherwise, the signature may be fraudulent or the message might have been altered.

Public Key Encryption: When one person wishes to send a secret message to another person, the first person looks up the second person's public key in a directory, uses it to encrypt the message and sends it off. The second person then uses their private key to decrypt the message and read it. No one listening in can decrypt the message. Anyone can send an encrypted message to the second person but only the second person can read it. Clearly, one requirement is that no one can figure out the private key from the corresponding public key.

Traffic Analysis: The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, Flow Identifiers used, and so on.

IPSec protocol (RFC 1825) provides IP network-layer encryption and defines a new set of headers to be added to IP datagrams. These new headers are placed after the IP header and before the Layer 4 protocol (typically TCP or UDP). They provide information for securing the payload of the IP packet, as described below:

The Authentication Header (AH) and Encapsulating Security Payload (ESP) can be used independently or together, although for most applications just one of them is sufficient. For both of these protocols, IPSec does not define the specific security algorithms to use, but rather, provides an open framework for implementing industry-standard algorithms. Initially, most implementations of IPSec support MD5 from RSA Data Security or the Secure Hash Algorithm (SHA) as defined by the US government for integrity and authentication. The DES is currently the most commonly offered bulk encryption algorithm, although RFCs are available that define how to use many other encryption systems, including IDEA, Blowfish, and RC4.

The AH is a mechanism for providing strong integrity and authentication for IP datagrams. It can also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed. For example, use of an asymmetric digital signature algorithm, such as RSA, could provide non- repudiation. Confidentiality and protection from traffic analysis are not provided by the AH. Users who need confidentiality should consider using the IP ESP, either in lieu of or in conjunction with the AH. The AH may appear after any other headers that are examined at each hop, and before any other headers that are not examined at an intermediate hop. The IPv4 or IPv6 header immediately preceding the AH will contain the value 51 in its Next Header (or Protocol) field.

The ESP can appear anywhere after the IP header and before the final transport-layer protocol. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to ESP. The header immediately preceding an ESP header always contains the value 50 in its Next Header (IPv6) or Protocol (IPv4) field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IP datagram or an upper-layer protocol frame (such as TCP or UDP).

IP ESP seeks to provide confidentiality and integrity by encrypting data to be protected and placing the encrypted data in the data portion of the IP ESP. Depending on the user's security requirements, this mechanism can be used to encrypt either a transport-layer segment (such as TCP, UDP, ICMP, IGMP) or an entire IP datagram. Encapsulating the protected data is necessary to provide confidentiality for the entire original datagram. Use of this specification will increase the IP protocol processing costs in participating systems and will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each IP datagram containing an ESP.

In Tunnel Mode ESP, the original IP datagram is placed in the encrypted portion of the ESP and that entire ESP frame is placed within a datagram having unencrypted IP headers. The information in the unencrypted IP headers is used to route the secure datagram from origin to destination. An unencrypted IP Routing Header might be included between the IP Header and the ESP.

This mode allows a network device, such as a router, to act as an IPSec proxy. That is, the router performs encryption on behalf of the hosts. The source's router encrypts packets and forwards them along the IPSec tunnel. The destination's router decrypts the original IP datagram and forwards it on to the destination system. The major advantage of tunnel mode is that the end systems do not need to be modified to enjoy the benefits of IP Security. Tunnel mode also protects against traffic analysis; with tunnel mode an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints. As defined by the IETF, IPSec transport mode can only be used when both the source and the destination systems understand IPSec. In most cases, you deploy IPSec with tunnel mode. Doing so allows you to implement IPSec in the network architecture without modifying the operating system or any applications on your PCs, servers, and hosts.

In Transport Mode ESP, the ESP header is inserted into the IP datagram immediately prior to the transport-layer protocol header (such as TCP, UDP, or ICMP). In this mode, bandwidth is conserved because there are no encrypted IP headers or IP options.

Only the IP payload is encrypted, and the original IP headers are left intact. This mode has the advantage of adding only a few bytes to each packet. It also allows devices on the public network to see the final source and destination of the packet. This capability allows you to enable special processing (for example, quality of service) in the intermediate network based on the information on the IP header. However, the Layer 4 header will be encrypted, limiting the examination of the packet. Unfortunately, by passing the IP header in the clear, transport mode allows an attacker to perform some traffic analysis. For example, an attacker could see when one CEO sent a lot of packets to another CEO. However, the attacker would only know that IP packets were sent; the attacker would not be able to determine if they were e-mail or another application.

While IPSec is the actual protocol that protects the IP datagrams, ISAKMP is the protocol that negotiates policy and provides a common framework for generating keys that IPSec peers share. It does not specify any details of key management or key exchange and is not bound to any key generation technique. Inside of ISAKMP, Cisco uses Oakley for the key exchange protocol. Oakley allows you to choose between five "well-known" groups. Cisco IOS supports group 1 (a 768 bit key) and group 2 (a 1024 bit key). Support for group 5 (a 1536 bit key) was introduced in Cisco IOS Software Release 12.1(3)T.

ISAKMP/Oakley creates an authenticated, secure tunnel between two entities, then negotiates the security association for IPSec. This process requires that the two entities authenticate themselves to each other and establish shared keys.

Both parties must be authenticated to each other. ISAKMP/Oakley supports multiple authentication methods. The two entities must agree on a common authentication protocol through a negotiation process using either RSA signatures, RSA encrypted nonces, or pre-shared keys.

Both parties must have a shared session key in order to encrypt the ISAKMP/Oakley tunnel. The Diffie-Hellman protocol is used to agree on a common session key. The exchange is authenticated as described above to guard against "man-in-the-middle" attacks.

These two steps, authentication and key exchanges, create the ISAKMP/Oakley session association (SA), which is a secure tunnel between the two devices. One side of the tunnel offers a set of algorithms; the other side must then accept one of the offers or reject the entire connection. When the two sides have agreed on which algorithms to use, they must derive key material to use for IPSec with AH, ESP, or both.

IPSec uses a different shared key than ISAKMP/Oakley. The IPSec shared key can be derived by using Diffie-Hellman again to ensure perfect forward secrecy, or by refreshing the shared secret derived from the original Diffie-Hellman exchange that generated the ISAKMP/Oakley SA by hashing it with pseudo-random numbers (nonces). The first method provides greater security but is slower. In most implementations, a combination of the two methods is used. That is, Diffie-Hellman is used for the first key exchange, and then local policy dictates when to use Diffie-Hellman or merely a key refresh. After this is complete, the IPSec SA is established.

Both RSA signatures and RSA encrypted nonces require the public key of the remote peer and they also require the remote peer to have your local public key. Public keys are exchanged in ISAKMP in the form of certificates. These certificates are obtained by enrolling in the Certificate Authority (CA). Currently, if there is no certificate in the router, ISAKMP does not negotiate the protection suite RSA signatures.

Cisco routers do not create certificates. Routers create keys, and request certificates for those keys. The certificates, which bind the routers' keys to their identities, are created and signed by certificate authorities. This is an administrative function, and the certificate authority always requires some sort of verification that the users are who they say they are. This means you cannot just create new certificates on the fly.

The communicating machines exchange preexisting certificates that they have obtained from certificate authorities. The certificates themselves are public information, but the corresponding private keys must be available to anybody who wants to use a certificate to prove identity. But they also must be kept secret from anybody who should not be able to use that identity.

A certificate may identify a user or a machine. It depends on the implementation. Most early systems probably use a certificate to identify a machine. If a certificate identifies a user, the private key corresponding to that certificate has to be stored in such a way that another user on the same machine cannot use it. That generally means that either the key is kept encrypted, or that the key is kept in a smart card. The encrypted-key case is likely to be more common in early implementations. In either case, the user generally has to enter a pass phrase whenever a key is activated.

Note: ISAKMP/Oakley uses UDP port 500 for negotiation. The AH contains 51 in the Protocol Field and ESP contains 50 in the Protocol Field. Make sure you are not filtering these.

For more information on the terminology used in this technical report, refer to the Definitions section.

The working sample Cisco IOS configurations in this document came directly from lab routers. The only alteration made to them was the removal of unrelated interface configurations. All of the material here came from freely available resources on the Internet or in the Related Information section at the end of this document.

Authentication via pre-shared keys is a non-public key alternative. Using this method, each peer shares a secret key that has been exchanged out-of-band and configured into the router. The ability for each side to demonstrate knowledge of this secret (without explicitly mentioning it) authenticates the exchange. This method is adequate for small installations but does have scaling problems. A pre-shared key of "sharedkey" is used below. If hosts share address-based preshared keys, they must use their address identity, which is the default in Cisco IOS Software, so it does not show in the configuration:

crypto isakmp identity address

Note: There are situations where ISAKMP cannot establish policy and keys for IPSec. If there is no certificate defined in the router and there are only public key-based authentication methods in ISAKMP policy, or if there is no certificate and no pre-shared keys for the peer (either shared directly by address or by a hostname that has been configured with that address), then ISAKMP cannot negotiate with the peer and IPSec does not work.

The following graphic represents the network diagram for this configuration.

Here are configurations for two routers (a Cisco 2511 and a Cisco 2516) back-to-back doing IPSec and ISAKMP authentication based on a preshared key. Comment lines are indicated by an exclamation point as the first character and are ignored if entered into the router. In the configuration below, comments precede certain configuration lines in order to describe them.

In this scenario, a shared secret key is not created. Each router generates its own RSA key. Then each router needs to configure the peer's RSA public key. This is a manual process and has obvious scaling limitations. In other words, a router needs to have a public RSA key for each peer with which it wishes to have a security association.

The following document represents the network diagram for this sample cofiguration.

In this example, each router generates an RSA key pair (you never see the RSA private key you generate) and configures the remote peers' public RSA key.

This example uses RSA signatures, which require the use of a CA server. Each peer obtains certificates from the CA server (this is usually a workstation that is configured to issue certificates). When both peers have valid CA certificates, they automatically exchange RSA public keys with each other as part of ISAKMP negotiation. All that is required in this scenario is for each peer to have registered with a CA and obtained a certificate. A peer no longer needs to keep public RSA keys of all the peers in a network.

Also, notice that an ISAKMP policy is not specified because you are using the default policy, which is shown below:

test1-isdn(config)#ip host cert-author 10.19.54.46
test1-isdn(config)#crypto key gen rsa usage
The name for the keys will be: test1-isdn.cisco.com
Choose the size of the key modulus in the range of 360 to 2048 for your
Signature Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus [512]:
Generating RSA keys ...
[OK]
Choose the size of the key modulus in the range of 360 to 2048 for your
Encryption Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus [512]:
Generating RSA keys ...
[OK]

Next, the CA configuration is defined with a tag called "test1-isdn-ultra" and defines the CA name URL. Then, authenticate with the CA server and obtain a certificate. Finally, keep checking to make sure you have received "Available" certificates for use.

The following graphic represents the network diagram for this sample configuration.

The sample configuration below is taken from two Cisco 1600 routers that have previously obtained CA certificates (as shown above) and intend to do ISAKMP with "rsa-sig" as the authentication policy. Only traffic between the two remote Ethernet LANs is encrypted.