Internet Key Exchange (IKE) is a standard method used to arrange
secure, authenticated communications. The Cisco VPN 5000 Concentrator uses IKE
to set up IPSec tunnels. These IPSec tunnels are the backbone of this product.
There are no specific requirements for this document.
The information in this document is based on these software and
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.
For more information on document conventions, refer to
Technical Tips Conventions.
IKE handles these tasks:
Authentication is the most important task that IKE accomplishes, and it
is the most complicated. Whenever you negotiate something, it is important to
know with whom you negotiate. IKE can use one of several methods to
authenticate negotiating parties to each other.
Shared key - IKE uses a hashing technique to ensure
that only someone who possesses the same key can send the IKE
Digital Signature Standard (DSS) or Rivest, Shamir, Adelman
(RSA) digital signatures - IKE uses public-key digital-signature
cryptography to verify that each party is who they claim to be.
RSA encryption - IKE uses one of two methods to
encrypt enough of the negotiation to ensure that only a party with the correct
private key can continue the negotiation.
During session negotiation, IKE allows parties to negotiate how they
will conduct authentication and how they will protect any future negotiations
(that is, IPSec tunnel negotiation). These items are negotiated:
Authentication method - This is one of the methods
listed in the Authentication section of this
Key exchange algorithm - This is a mathematical
technique for securely exchanging cryptographic keys over a public medium
(Diffie-Hellman). The keys are used in the encryption and packet-signature
Encryption algorithm - Data Encryption Standard
(DES) or Triple Data Encryption Standard (3DES).
Packet signature algorithm - Message Digest 5 (MD5)
and Secure Hash Algorithm 1 (SHA-1).
IKE uses the negotiated key-exchange method (see the
Session Negotiation section of this document) to
create enough bits of cryptographic keying material to secure future
transactions. This method ensures that each IKE session is protected with a
new, secure set of keys.
Authentication, session negotiation, and key exchange constitute phase
one of an IKE negotiation. For a VPN 5000 Concentrator, these properties are
configured in the IKE Policy section through the Protection
keyword. This keyword is a label which has three pieces: authentication
algorithm, encryption algorithm, and key exchange algorithm. The pieces are
separated by an underscore. The label MD5_DES_G1 means use MD5 for IKE-packet
authentication, use DES for IKE-packet encryption, and use Diffie-Hellman group
1 for key exchange. For more information, refer to
the IKE Policy for IPSec Tunnel Security.
After IKE has finished negotiating a secure method for exchanging
information (phase one), IKE is used to negotiate an IPSec tunnel. This is
accomplished using IKE phase two. In this exchange, IKE creates fresh keying
material for the IPSec tunnel to use (either using the IKE phase one keys as a
base or by performing a new key exchange). The encryption and authentication
algorithms for this tunnel are also negotiated.
IPSec tunnels are configured using the VPN Group (formerly the Secure
Tunnel Establishment Protocol (STEP) Client) section for VPN Client tunnels and
the Tunnel Partner section for LAN-to-LAN tunnels. The VPN
Users section is where the authentication method for each user is
stored. These sections are documented in
the IKE Policy for IPSec Tunnel Security.
RADIUS - IKE has no support for RADIUS
authentication. RADIUS authentication is performed in a special information
exchange that takes place after the first IKE packet from the VPN Client. If
Password Authentication Protocol (PAP) is required, a special RADIUS
authentication secret is required. For more information, refer to the
documentation of NoCHAP and PAPAuthSecret in
the IKE Policy for IPSec Tunnel Security. RADIUS authentication is
authenticated and encrypted. The PAP exchange is protected by the
PAPAuthSecret. However, there is only one such secret for the entire IntraPort,
so the protection is as weak as any shared password.
SecurID - IKE currently has no support for SecurID
authentication. SecurID authentication is performed in a special informational
exchange in between phase one and phase two. This exchange is fully protected
by the IKE Security Association (SA) negotiated in phase one.
Secure Tunnel Access Management Protocol (STAMP) -
VPN Client connections exchange information with the IntraPort during the IKE
process. Information such as if it is all right to save secrets, which IP
networks to tunnel, or whether to tunnel Internetwork Packet Exchange (IPX)
traffic, is sent in private payloads during the last two IKE packets. These
payloads are only sent to compatible VPN
The Internet Security Association and Key Management Protocol (ISAKMP)
is a language used to conduct negotiations across the Internet (for example,
using the IP protocol). Oakley is a method for conducting an authenticated
exchange of cryptographic key material. IKE puts the two together into one
package, which allows secure connections to be set up across the unsecure
Secure Tunnel Establishment Protocol (STEP) is the previous name of the
VPN system. In the pre-IKE days, STAMP was used to negotiate IPSec connections.
The VPN Client versions earlier than 3.0 use STAMP to establish a connection
with an IntraPort.