Mask Preshared Keys; Preshared Keys Using A Aaa Server - Cisco IOS XR Configuration Manual

Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
criteria imposes the granularity of applying the specified parameters. The ISAKMP profile applies
parameters specific to each profile, such as trust points, peer identities, and XAUTH authentication,
authorization, and accounting (AAA) list, and so forth.
ISAKMP Profile Considerations
The following considerations are listed on when to use the ISAKMP profile:
•
•
•

Mask Preshared Keys

A mask preshared key lets a group of remote users with the same level of authentication share an IKE
preshared key. The preshared key of the remote peer must match the preshared key of the local peer for
IKE authentication to occur.
A mask preshared key is usually distributed through a secure out-of-band channel. In a remote
peer-to-local peer scenario, any remote peer with the IKE preshared key configured can establish IKE
SAs with the local peer.
If you specify a subnet-address value with the crypto keyring command, it is up to you to use a subnet
address, which allows more peers to share the same key. That is, the preshared key is no longer restricted
to use between two users.
Note We do not recommend using 0.0.0.0 as a subnet address, because it encourages group preshared keys,
which allow all peers to have the same group key, thereby reducing the security of your user
authentication.
Mask preshared keys have the following restrictions:
•
•

Preshared Keys Using a AAA Server

Preshared keys do not scale well when you are trying to deploy a large scale Virtual Private Network
(VPN) without using a CA. When dynamic IP addressing such as DHCP or PPP dialups is used, the
changing IP address can make key lookup difficult or impossible unless a mask preshared key is used.
However, mask preshared keys are not very secure because a large number of users are given the same
secret, thus reducing the security of the secret.
Information About Implementing IKE Security Protocol Configurations for IPSec Networks
Any router with two or more IPSec connections that requires different phase 1 parameters for
different sites (for example, configuring site-to-site and remote access on the same router).
Custom Internet Key Exchange (IKE) Phase 1 policies might be needed for different peers. For
example, whether XAUTH is applied to a specific peer, rather than being applied on every
connection.
IPSec configuration using VRF-aware IPSec, which allows the use of single IP address to connect
to different peers with different IKE Phase 1 parameters.
The SA cannot be established between the IPSec peers until all IPSec peers are configured for the
same preshared key.
The mask preshared key must be distinctly different for remote users requiring varying levels of
authorization. You must configure a new preshared key for each level of trust and assign the correct
keys to the correct parties. Otherwise, an untrusted party may obtain access to protected data.
Cisco IOS XR System Security Configuration Guide
SC-27