This section presents an overview of the major IPSec configuration
tasks that must be performed to build a site-to-site IPSec VPN or a
router-to-router IPSec VPN using pre-shared keys. Site-to-site IPSec VPNs can
be established between any combination of routers, PIX Security Appliances, VPN
concentrators, VPN clients, and other devices that are IPSec compliant.
The use of pre-shared keys for authentication of IPSec sessions is
relatively easy to configure, yet does not scale well for a large number of
IPSec clients. The process for configuring IKE pre-shared keys in Cisco IOS
software for Cisco routers consists of the following four major tasks:
- Task 1 is to prepare for IPSec. This task involves determining the detailed
encryption policy, identifying the hosts and networks to protect, determining
details about the IPSec peers, determining the needed IPSec features, and
ensuring existing ACLs are compatible with IPSec.
- Task 2 involves configuring IKE. This task includes enabling IKE, creating
the IKE policies, and validating the configuration.
- Task 3 is configuring IPSec. This task includes defining the transform
sets, creating crypto ACLs, creating crypto map entries, and applying crypto
map sets to interfaces.
- Task 4 is to test and verify IPSec. Using show,
debug, and related commands to test and verify that IPSec
encryption works. These commands can also be used to troubleshoot
problems.
IKE peer authentication using pre-shared secrets is the simplest
authentication to configure, but has several serious limitations. The
authentication is based on a pre-shared secret. Both peers share a secret
password string between them. This secret is exchanged securely out-of-band.
During the IKE peer authentication process, peers perform a PPP CHAP-like
exchange of random values, hashed with the pre-shared secret key.
Authentication via pre-shared secrets uses hashing and is therefore very fast.
IKE peer authentication using pre-shared secrets works in the following manner.
the following description is simplified for clarity:
- Peer A randomly chooses a string and sends it to peer B.
- Peer B hashes the received string together with the pre-shared secret and
yields a hash value, dependent on the random string and the pre-shared
secret.
- Peer B sends the result of hashing back to peer A.
- Peer A calculates its own hash of the random string, together with the
pre-shared secret, and matches it with the received result from the other peer.
If they match, peer B knows the pre-shared secret, and is considered
authenticated.
- Now peer B randomly chooses a different random string and sends it to peer
A.
- Peer A also hashes the received string with the pre-shared secret.
- Peer A sends the authenticated hash back to peer B.
- Peer B locally hashes the random value and the pre-shared secret and
matches it against the received authenticated hash. If they are equal, peer A
is also authenticated.
When both peers authenticate each other, the peer authentication
procedure is complete. The main limitation of pre-shared secret authentication
is the requirement to base the pre-shared secret on the IP address of the
remote peer, not its IKE identity. This can impose significant problems in an
environment with dynamic peer addresses such as dial-up users, DHCP users, and
so on.