Table of Contents
Advertisement
IKE SA Negotiation
Generating Private and Public Key Pairs
Copyright © 2010, Juniper Networks, Inc.
For digital certificate authentication, an initiator signs message interchange data using
his private key, and a responder uses the initiator's public key to verify the signature.
Typically, the public key is exchanged via messages containing an X.509v3 certificate.
This certificate provides a level of assurance that a peer's identity (as represented in
the certificate) is associated with a particular public key.
For more information, see "Configuring Digital Certificates" on page 205.
Preshared keys
With preshared key authentication mode, the same secret string (similar to a password)
must be configured on both security gateways before the gateways can authenticate
each other. It is not advisable to share a preshared key among multiple pairs of security
gateways, because it reduces the key's security level.
The router allows preshared keys to be up to 256 ASCII alphanumeric characters.
Diffie-Hellman Group
An IKE policy must specify which Diffie-Hellmann group is used during the symmetrical
key generation phase of IKE. The following Diffie-Hellmann groups are supported:
Group 1 (768-bit)
Group 2 (1024-bit)
Group 5 (1536-bit)
Lifetime
Like a user SA, an IKE SA does not last indefinitely. Therefore, the router allows you to
specify a lifetime parameter for an IKE policy. The timer for the lifetime parameter begins
when the IKE SA is established using IKE.
As the initiator of an IKE SA, the router sends its IKE policies to the remote peer. If the
peer has an IKE policy that matches the encryption, hash, authentication method, and
Diffie-Hellmann group settings, the peer returns the matching policy. The peers use the
lesser lifetime setting as the IKE SA lifetime. If no match is found, the IKE SA fails, and a
log alarm is generated.
As the responder of an IKE negotiation, the router receives all IKE policies from a remote
security gateway. The router then scans its own list of IKE policies to determine whether
a match exists, starting from the highest priority. If it finds a match, that policy is
successfully negotiated. Again, the lifetime is negotiated to the lesser of the two lifetimes,
and failures are logged.
When any of the public key methods for authenticating remote security gateways is used,
the system must have at least one valid pair of public or private keys. Therefore, the
system provides a facility by which it can generate public and private key pairs for itself.
The private key is used only by the system itself. It is never exchanged with any other
nodes. When generated, the private key is securely stored internally to the system in
Chapter 5: Configuring IPSec
137
Advertisement
Table of Contents
