This chapter is from the book
This chapter is from the book
This chapter is from the book
IKE Overview
IKE negotiates the IPSec security associations (SAs). This process requires that the IPSec systems first authenticate themselves to each other and establish ISAKMP, or IKE, shared keys.
In phase one, IKE creates an authenticated secure channel between the two IKE peers that is called the IKE Security Association. The Diffie-Hellman key agreement is always performed in this phase.
In phase two, IKE negotiates the IPSec security associations and generates the required key material for IPSec. The sender offers one or more transform sets that are used to specify an allowed combination of transforms with their respective settings. The sender also indicates the data flow to which the transform set is to be applied. The sender must offer at least one transform set. The receiver then sends back a single transform set, which indicates the mutually agreed-on transforms and algorithms for this particular IPSec session. A new Diffie-Hellman agreement can be done in phase two, or the keys can be derived from the phase one shared secret.
Figure 1-13 shows the role that IKE takes in the IPSec VPN creation process.
){kind=link}
NOTE
A security association (SA) is a relationship between two or more entities that describes how the entities will use security services to communicate securely. SAs are covered in detail later in this chapter in the "IPSec Security Associations" section.
Figure 1-13 The Function of IKE
IKE authenticates the peer and the IKE messages between the peers during IKE phase one. Phase one consists of main mode or aggressive mode. Potential peers in an IPSec session must authenticate themselves to each other before IKE can proceed. Peer authentication occurs during the main mode exchange during IKE phase one. The IKE protocol is very flexible and supports multiple authentication methods as part of the phase one exchange. The two entities must agree on a common authentication protocol through a negotiation process. IKE phase one has three methods to authenticate IPSec peers in Cisco products, which are as follows:
Preshared keys—A key value entered into each peer manually (out of band) used to authenticate the peer
RSA signatures—Use a digital certificate authenticated by an RSA signature
RSA encrypted nonces—Use RSA encryption to encrypt a nonce value (a random number generated by the peer) and other values
A common value used by all authentication methods is the peer identity (ID), which helps identify the peer. Some ID values used are as follows:
IP address of the peer (four octets), such as 172.30.2.2
Fully qualified domain name (FQDN), such as student@cisco.com
Preshared Keys
With preshared keys, the same preshared key is configured on each IPSec peer. IKE peers authenticate each other by computing and sending a keyed hash of data that includes the preshared key. If the receiving peer is able to create the same hash independently using its preshared key, it knows that both peers must share the same secret, thus authenticating the other peer. Preshared keys are easier to configure than manually configuring IPSec policy values on each IPSec peer. However, preshared keys do not scale well because each IPSec peer must be configured with the preshared key of every other peer with which it will establish a session.
RSA Signatures
The RSA signatures method uses a digital signature, where each device digitally signs a set of data and sends it to the other party. RSA signatures use a CA to generate a unique identity digital certificate that is assigned to each peer for authentication. The identity digital certificate is similar in function to the preshared key, but provides much stronger security.
RSA is a public-key cryptosystem used by IPSec for authentication in IKE phase 1. RSA was developed in 1977 by Ronald Rivest, Adi Shamir, and Leonard Adelman.
The initiator and the responder to an IKE session using RSA signatures send their own ID value (IDi, IDr), their identity digital certificate, and an RSA signature value consisting of a variety of IKE values, all encrypted by the negotiated IKE encryption method (DES or 3DES).
RSA Encryption
The RSA-encrypted nonces method uses the RSA encryption public key cryptography standard. The method requires that each party generates a pseudorandom number (a nonce) and encrypt it in the other party's RSA public key. Authentication occurs when each party decrypts the other party's nonce with a local private key (and other publicly and privately available information) and then uses the decrypted nonce to compute a keyed hash. This system provides for deniable transactions. That is, either side of the exchange can plausibly deny that it took part in the exchange. Cisco IOS software is the only Cisco product that uses RSA encrypted nonces for IKE authentication. RSA encrypted nonces use the RSA public key algorithm.
CAs and Digital Certificates
The distribution of keys in a public key scheme requires some trust. If the infrastructure is untrusted and control is questionable, such as on the Internet, distribution of keys is troublesome. RSA signatures are used by CAs, which are trusted third-party organizations. Verisign, Entrust, and Netscape are examples of companies that provide digital certificates. To get a digital certificate, a client registers with a CA. After a CA verifies the client's credentials, a certificate is issued. The digital certificate is a package that contains information such as a certificate bearer's identity: his or her name or IP address, the certificate's serial number, the certificate's expiration date, and a copy of the certificate bearer's public key. The standard digital certificate format is defined in the X.509 specification. X.509 version 3 defines the data structure for certificates and is the standard that Cisco supports. Figure 1-14 identifies some key points of CA operation.
){kind=link}
Figure 1-14 CAs and Digital Certificates