IPSec Fundamentals - Part II

In the first part of IPSec Fundamentals we had a general view of what IPSec can do and how.

In this part we will go deeper inside this technology to discover how it works and how is currently used to protect traffic over the Internet

IPSec features Data Origin Authentication provided by IKE depends upon mutual authentication of both ends of secure communication channel, this authentication can be done using:

• Pre-configured username and password on endpoints


• OTP (One-time password) such as PIN o single-time transactions


• Biometric authentication


• Pre-shared Keys


• Digital certificates

IPSec Data integrity and anti-replay provided by AH and ESP depend upon hashing. Following methods are available:

• SHA-1 (weaker)


• MD5

IPSec Data Confidentiality provided by ESP depend upon encryption algorithms:

• DES


• 3-DES


• AES

Now we have all the elements that compose IPSec architecture, we have protocols, authentication methods, hashing and encrypting algorithms and two different modes to use them. In the next section we will see how an IPSec connection is established and how secure communications are built over this connection.

The whole IPSec features use a secure, bi-directional or mono-directional channels named SAs (Security Association) that are agreement of IPSec parameters between two peers

IKE (Internet Key Exchange) is a protocol that allows two hosts to exchange a private key (like a password) and IPSec parameters in a secure way over an unsecure connection. IKE can use two different existing protocol to complete this task:

• ISAKMP (Internet Secure Association and Key Management Protocol) that provides both SA creation/deletion, key exchange and peers authentication


• Oakley that uses Diffie-Hellman algorithm to exchange keys

The need to have a secure key exchange capability is due to the fact that passwords or pre-shared keys are often manually configured, so you actually need a way to exchange and/or update passwords to other peers.

IKE job is divided into two main phases:

• IKE Phase 1 (mandatory)
  
  
  in this phase the two peers negotiate common IPSec connection parameters and peer authentication takes place.
  
  
  If both peers agree on IPSec parameters and succesfully authenticate each other, a bi-directional SA is established
  
  
  IKE Phase 1 can be initiated in two modes:


• 
  
  
  
  • IKE Phase 1 Main Mode
  
  
  • IKE Phase 1 Aggressive Mode
  
  
  
  


• IKE Phase 1.5 (optional)
  
  
  in phase 1 both peers authenticate each other, but if user behind the device requesting the connection must be authenticated too, it can be done using Xauth to request login to end user and authenticate him before granting IPSec connection


• IKE Phase 2 (mandatory)
  
  
  in this phase mono-directional SAs are created between IPSec endpoints using IKE Quick Mode. The new SAs uses different keys for each SA

So we have seen how IKE is the protocol that allows two IPSec peers to establish a connection, the two main phases, IKE Phase 1 and IKE Phase 2 and the three different IKE Modes: IKE Quick Mode and IKE Aggressive Mode for Phase 1 and IKE Quick Mode for Phase 2.

It may sound a little tricky, but just think about it: you have two peers that need to make a secure connection *before* authenticating each other, now you first need a protocol to provide you a way to establish this connection. This is IKE. Since with IPSec you can use different protocols (AH and ESP), different modes (tunnel or transport), different algorithms for hashing and encryption, you need this protocol to negotiate these parameters before you can use this connection.

In second stage, you need a *secure* channel, so you must authenticate your peer and it will authenticate you too. Additionally, you may want to change your passwords or pre-shared keys for security purpose or because they were compromised, so you will need a way to exchange or update keys to make your solution scalable and manageable.

Let's take a look to the connection process: you initiate a connection to a remote router, so we are in IKE Phase 1 where we can have IKE Main Mode or IKE Aggressive Mode. First of all we must agree about IPSec connection parameters, then we must exchange our keys to provide a secure channel for authentication process. Last we authenticate each other and establish a bi-directional SA.

Once we have a secure channel, things are less complicated, so IKE Phase 2 can use IKE Quick Mode to establish new SAs (uni-directional) that will be used for data encryption and this can be done using our existing secure channel, over which we will exchange parameters and keys for new SAs

Some details on IKE Modes

IKE Main Mode (6 packets):

• The initiator sends parameters set proposals, the responders select the appropriate one


• Diffie-Hellman is used to exchange public keys between peers


• ISAKMP is used to authenticate the session for both peers


• The bi-directional SA is established

IKE Aggressive Mode (3 packets):

• The initiator sends parameters, policies and Diffie-Hellman public keys


• The responder authenticates the packet, then sends parameters proposal, keys and authentication back


• The initiator authenticates the packet


• The bi-directional SA is established

IKE Quick Mode

• Negotiates SA parameters


• Key exchange for specific SA

Control and management of SAs is also provided by IKE:

• DPD (Dead Peer Detection)
  
  
  a keepalive is sent (10s by default) to detect if remote peer is responding


• NAT Transversal
  
  
  during IKE Phase 1 if NAT is detected through connection, an additional UDP header is added to support this configuration


• Mode configuration
  
  
  can be used to send to the initiator client all of the configuration settings for connection (f.e. Cisco Easy VPN)


• XAuth