D-Link DFL-2500 - Manual (Page 241)

IKE Negotiation
The process of negotiating session parameters consists of a number of phases and modes. These are
described in detail in the below sections.
The flow of events can summarized as follows:
IKE Phase-1
• Negotiate how IKE should be protected
IKE Phase-2
• Negotiate how IPsec should be protected
• Derive some fresh keying material from the key exchange in phase-1, to
provide session keys to be used in the encryption and authentication of the
VPN data flow
IKE and IPsec Lifetimes
Both the IKE and the IPsec connections have limited lifetimes, described both in terms of time
(seconds), and data (kilobytes). These lifetimes prevent a connection from being used too long,
which is desirable from a crypto-analysis perspective.
The IPsec lifetime must be shorter than the IKE lifetime. The difference between the two must be a
minimum of 5 minutes. This allows for the IPsec connection to be re-keyed simply by performing
another phase-2 negotiation. There is no need to do another phase-1 negotiation until the IKE
lifetime has expired.
IKE Proposals
An IKE proposal is a suggestion of how to protect data. The VPN device initiating an IPsec
connection, the initiator, will send a list of proposals, a proposal-list, suggesting different methods
of how to protect the connection.
The connection being negotiated can be either an IPsec connection protecting the data flow through
the VPN, or it can be an IKE connection, protecting the IKE negotiation itself.
The responding VPN device, upon receiving this proposal-list, will choose the most suitable
proposal according to its own security policy, and respond by specifying which one of the proposal
it has chosen.
If no acceptable proposal can be found, it will respond by saying that no proposal could be accepted,
and possibly provide a reason why.
The proposals contain all parameters needed, such as algorithms used to encrypt and authenticate
the data, and other parameters as described in section IKE Parameters.
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 firewalls 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 intially agree a shared secret
between the two parties in the negotiation and to derive keys for encryption.
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN
241