25-5
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter25 Configuring IKE and IPsec Policies
Understanding IKE
Related Topics
•Overview of IKE and IPsec Configurations, page25-2
•Configuring an IKE Proposal, page 25-9
Understanding IKE
Internet Key Exchange (IKE), also called Internet Security Association and Key Management Protocol
(ISAKMP), is the negotiation protocol that lets two hosts agree on how to build an IPsec security
association (SA). It provides a common framework for agreeing on the format of SA attributes. This
includes negotiating with the peer about the SA, and modifying or deleting the SA. IKE creates the
cryptographic keys used to authenticate IPsec peers, negotiates and distributes IPsec encryption keys,
and automatically establishes IPsec security associations.
The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE
peers, creating the first tunnel that enables the peers to communicate securely in Phase 2, protecting later
ISAKMP negotiation messages. During Phase 2 negotiation, IKE establishes SAs for other applications,
such as IPsec, which protects the data sent between peers. Both phases use proposals when they negotiate
a connection.
An IKE proposal is a set of algorithms that two peers use to secure the IKE negotiation between them.
IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which
security parameters will be used to protect subsequent IKE negotiations. In remote access IPsec VPNs,
you can define several IKE proposals per VPN to create multiple, prioritized policies at each peer to
ensure that at least one policy matches a remote peer’s policy. For site-to-site VPNs, you can create a
single IKE proposal.
To define an IKE proposal, you must specify:
•A unique priority (1 through 65,543, with 1 the highest priority).
•An encryption method for the IKE negotiation, to protect the data and ensure privacy. See Deciding
Which Encryption Algorithm to Use, page 25-6.
•A Hashed Message Authentication Codes (HMAC) method (called integrity algorithm in IKEv2) to
ensure the identity of the sender, and to ensure that the message has not been modified in transit.
See Deciding Which Hash Algorithm to Use, page 25-6.
•For IKEv2, a separate pseudo-random function (PRF) used as the algorithm to derive keying
material and hashing operations required for the IKEv2 tunnel encryption. The options are the same
as those used for the hash algorithm; see Deciding Which Hash Algorithm to Use, page 25-6.
•A Diffie-Hellman group to determine the strength of the encryption-key-determination algorithm.
The device uses this algorithm to derive the encryption and hash keys. See Deciding Which
Diffie-Hellman Modulus Group to Use, page 25-7.
•An authentication method, to ensure the identity of the peers. See Deciding Which Authentication
Method to Use, page 25-8.
•A limit to the time the device uses an encryption key before replacing it.
Tip (ASA devices only.) With IKEv1 policies, for each parameter, you set one value. For IKEv2, you can
configure multiple encryption, integrity, PRF, and Diffie-Hellman options. The ASA orders the settings
from the most secure to the least secure and negotiates with the peer using that order. This allows you to
potentially send a single proposal to convey all the allowed transforms instead of the need to send each
allowed combination as with IKEv1.