Amer Networks E5Web GUI - Manual (Page 583)

will reply by saying that nothing on the list was acceptable, and possibly also provide a textual
explanation for diagnostic purposes.
This negotiation to find a mutually acceptable algorithm combination is done not just to find the
best way to protect the IPsec connection but also to find the best way to protect the IKE
negotiation itself.
Algorithm proposal lists contain not just the acceptable algorithm combinations for encrypting
and authenticating data but also other IKE related parameters. Further details of the IKE
negotiation and the other IKE parameters are described next.
IKE Phase-1 - IKE Security Negotiation
An IKE negotiation is performed in two phases. The first phase, phase 1, is used to authenticate
the two VPN gateways or VPN Clients to each other, by confirming that the remote device has a
matching Pre-Shared Key.
However, since we do not want to publish to much of the negotiation in plaintext, we first agree
upon a way of protecting the rest of the IKE negotiation. This is done, as described in the
previous section, by the initiator sending a proposal-list to the responder. When this has been
done, and the responder accepted one of the proposals, we try to authenticate the other end of
the VPN to make sure it is who we think it is, as well as proving to the remote device that we are
who we claim to be. A technique known as a Diffie Hellman Key Exchange is used to initially agree
a shared secret between the two parties in the negotiation and to derive keys for encryption.
Authentication can be accomplished through Pre-Shared Keys, certificates or public key
encryption. Pre-Shared Keys is the most common authentication method today. PSK and
certificates are supported by the cOS Core VPN module.
IKE Phase-2 - IPsec Security Negotiation
In phase 2, another negotiation is performed, detailing the parameters for the IPsec connection.
During phase 2 we will also extract new keying material from the Diffie-Hellman key exchange in
phase 1 in order to provide session keys to use in protecting the VPN data flow.
If Perfect Forwarding Secrecy (PFS) is used, a new Diffie-Hellman exchange is performed for each
phase 2 negotiation. While this is slower, it makes sure that no keys are dependent on any other
previously used keys; no keys are extracted from the same initial keying material. This is to make
sure that, in the unlikely event that some key was compromised, no subsequent keys can be
derived.
Once the phase 2 negotiation is finished, the VPN connection is established and ready for traffic
to pass through it.
IPsec Tunnel Properties
Below is a summary of the key properties required of an IPsec tunnel object. Understanding what
these properties do before attempting to configure the tunnel is strongly recommended, since it
is of great importance that both tunnel endpoints can agree.
With two Clavister Security Gateways as IPsec endpoints, the matching process is greatly
simplified since the default cOS Core configuration parameters will be the same at either end.
However, it may not be as straightforward when equipment from different vendors is involved in
establishing the VPN tunnel.
Endpoint Identification The Local ID is a piece of data representing the identity of
the VPN tunnel endpoint. With Pre-Shared Keys this is a
Chapter 9: VPN
583