VPN Security

IPsec VPN traffic is secured in two stages:

•
Authentication: The first phase establishes the authenticity of the sender and receiver of the traffic using an exchange of the public key portion of a public-private key pair. This phase must be successful before the VPN tunnel can be established.
•
Encryption: The traffic in the VPN tunnel is encrypted, using an encryption algorithm such as AES or 3DES.

Unless you use a manual key (which must be typed identically into each node in the VPN) The exchange of information to authenticate the members of the VPN and encrypt/decrypt the data uses the Internet Key Exchange (IKE) protocol for exchanging authentication information (keys) and establishing the VPN tunnel. SonicOS supports two versions of IKE:

•
IKE version 1
•
IKEv2
IKE version 1

IKE version 1 uses a two phase process to secure the VPN tunnel.

•
IKE Phase 1 is the authentication phase. The nodes or gateways on either end of the tunnel authenticate with each other, exchange encryption/decryption keys, and establish the secure tunnel. See IKE Phase 1.
•
IKE Phase 2 is the negotiation phase. Once authenticated, the two nodes or gateways negotiate the methods of encryption and data verification (using a hash function) to be used on the data passed through the VPN and negotiate the number of secure associations (SAs) in the tunnel and their lifetime before requiring renegotiation of the encryption/decryption keys. See IKE Phase 2.
IKE Phase 1

In IKE v1, there are two modes of exchanging authentication information: Main Mode and Aggressive Mode.

•
Main Mode: The node or gateway initiating the VPN queries the node or gateway on the receiving end, and they exchange authentication methods, public keys, and identity information. This usually requires six messages back and forth. The order of authentication messages in Main Mode is:
a
The initiator sends a list of cryptographic algorithms the initiator supports.
b
The responder replies with a list of supported cryptographic algorithms.
c
The initiator send a public key (part of a Diffie-Hellman public/private key pair) for the first mutually supported cryptographic algorithm.
d
The responder replies with the public key for the same cryptographic algorithm.
e
The initiator sends identity information (usually a certificate).
f
The responder replies with identity information.
•
Aggressive Mode: To reduce the number of messages exchanged during authentication by half, the negotiation of which cryptographic algorithm to use is eliminated. The initiator proposes one algorithm and the responder replies if it supports that algorithm:
a
The initiator proposes a cryptographic algorithm to use and sends its public key.
b
The responder replies with a public key and identity proof.
c
The initiator sends an identification proof. After authenticating, the VPN tunnel is established with two SAs, one from each node to the other.
IKE Phase 2

In IKE phase 2, the two parties negotiate the type of security to use, which encryption methods to use for the traffic through the tunnel (if needed), and negotiate the lifetime of the tunnel before re-keying is needed.

The two types of security for individual packets are:

•
Encryption Secured Payload (ESP), in which the data portion of each packet is encrypted using a protocol negotiated between the parties.
•
Authentication Header (AH), in which the header of each packet contains authentication information to ensure the information is authenticated and has not been tampered with. No encryption is used for the data with AH.

SonicOS supports the following encryption methods for Traffic through the VPN.

•
DES
•
3DES
•
AES-128
•
AES-192
•
AES-256

You can find more information about IKE v1 in the three specifications that define initially define IKE, RFC 2407, RFC 2408, and RFC 2409, available on the Web at:

•
http://www.faqs.org/rfcs/rfc2407.html
•
http://www.faqs.org/rfcs/rfc2408.html
•
http://www.faqs.org/rfcs/rfc2409.html
IKEv2

IKE version 2 is a new protocol for negotiating and establishing SAs. IKEv2 features improved security, a simplified architecture, and enhanced support for remote users. In addition, IKEv2 supports IP address allocation and EAP to enable different authentication methods and remote access scenarios. Using IKEv2 greatly reduces the number of message exchanges needed to establish an SA over IKE v1 Main Mode, while being more secure and flexible than IKE v1 Aggressive Mode. This reduces the delays during re-keying. As VPNS grow to include more and more tunnels between multiple nodes or gateways, IKEv2 reduces the number of SAs required per tunnel, thus reducing required bandwidth and housekeeping overhead.

IKEv2 is not compatible with IKE v1. If using IKEv2, all nodes in the VPN must use IKEv2 to establish the tunnels.

SAs in IKEv2 are called Child SAs and can be created, modified, and deleted independently at any time during the life of the VPN tunnel.

Topics:
•
Initialization and Authentication in IKEv2
•
Negotiating SAs in IKEv2
•
Negotiating SAs in IKEv2
•
Configuration Payload
•
Windows 7 IKEv2 Client
Initialization and Authentication in IKEv2

IKEv2 initializes a VPN tunnel with a pair of message exchanges (two message/response pairs).

•
Initialize communication: The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces (random values generated and sent to guard against repeated messages), and perform a public key exchange.
•
Initiator sends a list of supported cryptographic algorithms, public keys, and a nonce.
•
Responder sends the selected cryptographic algorithm, the public key, a nonce, and an authentication request.
•
Authenticate: The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first CHILD_SA. Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers and all fields in all the messages are authenticated.
•
Initiator sends identity proof, such as a shared secret or a certificate, and a request to establish a child SA.
•
Responder sends the matching identity proof and completes negotiation of a child SA.
Negotiating SAs in IKEv2

This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKE v1. It may be initiated by either end of the SA after the initial exchanges are completed.

All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange.

Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term “initiator” refers to the endpoint initiating this exchange.

1
Initiator sends a child SA offer and, if the data is to be encrypted, the encryption method and the public key.
2
Responder sends the accepted child SA offer and, if encryption information was included, a public key.
Configuration Payload

The IKEv2 configuration payload (CP) allows the VPN server to dynamically assign IP addresses to remote clients. The client and server exchange information, similar to a DHCP negotiation as if the client was directly connected to a LAN.

When IKEv2 is selected as the exchange method for the IKE phase 1 proposal, the administrator can choose to assign the client an IP address from the IKEv2 IP address pool.

IKEv2 configuration payloads are intended for relatively small-scale deployments.

Windows 7 IKEv2 Client

When used with SonicWall appliances, the Windows 7 IKEv2 client must use third party certificates as the authentication method. The certificates installed on the remote access server should have the following values:

•
Common Name (CN): This field must contain the fully qualified DNS name or IP address of the remote access server. If the server is located behind a network address translating (NAT) router, then the certificate must contain the fully qualified DNS name or IP address of the external connection of the NAT router (the address that the client computer sees as the address of the server).
•
EKU: This field must includes Server Authentication. If there is more than one server authentication certificate, additionally include the IP security IKE intermediate EKU. Only one certificate should have both EKU options, otherwise IPsec cannot determine which certificate to use, and might not pick the certificate you intended. For more information, see:

http://technet.microsoft.com/en-us/library/dd941612(WS.10).aspx.

* 
NOTE: You can find more information about IKEv2 in the specification, RFC 4306, available on the Web at: http://www.ietf.org/rfc/rfc4306.txt.