Thursday, 24 July 2014

My IPSEC Notes

IPSec is used to transfer data between sites in an encrypted manner. There are two basic techniques for encrypting information: symmetric encryption and asymmetric encryption.

With Symmetric encryption both parties share the same key. This allows the sender to encrypt the information using the shared key and the receiver to decrypt this using the same key. The main problem then becomes how the two parties negotiate the same key.

With Asymmetric encryption both parties have their own keys. The sender encrypts the information using one key and the receiver decrypts the information using another key.

IPsec uses symmetric encryption and uses Diffie–Hellman key exchange (DH) to generate the same key at each site. DH works like this:
  1. Alice and Bob agree to use a prime number p = 23 and base g = 5.
  2. Alice chooses a secret integer a = 6, then sends Bob A = ga mod p
    • A = 56 mod 23 = 8
  3. Bob chooses a secret integer b = 15, then sends Alice B = gb mod p
    • B = 515 mod 23 = 19
  4. Alice computes s = Ba mod p
    • s = 196 mod 23 = 2
  5. Bob computes s = Ab mod p
    • s = 815 mod 23 = 2
  6. Alice and Bob now share a secret (the number 2).
If the prime numbers are large enough then the shared secret is considered to be secure as it would take a long time for a computer to test all the options.

However the critical problem with DH is that it’s vulnerable to a man-in-the-middle attack. This basically means that Eve could sit in the middle and negotiate a secret with Alice and different secret with Bob. Eve could then listen to all the traffic between Alice and Bob.

IPSec solves this problem by authenticating Alice and Bob using pre-shared-keys (PSK), Certificates or RSA keys.

This problem of authentication and DH is wrapped up into Internet Key Exchange (IKE) protocol which IPSec uses to ensure secrecy between the parties. IKE has two phases, Phase one negotiates the following:
s    a)  Which prime numbers & base to use
b)      Which encryption to use in Phase two
c)       Generation of the DH shared secret
d)      Authentication of the endpoints using PSK or Certs / RSA

Phase 2 uses the encryption algorithm decided in phase one to encrypt its packets and within this encryption it negotiates the following

a)   The encryption method to use for encrypting the data packets between the end points (IPsec
      b)      The shared secret for this encryption

This potentially means that you could have the different encryption methods for Phase 2 and IPsec. It would be wise to set these differently as it increases the overall security of the communications. I would suggest that you use AES256 for Phase 2 and AES 128 for IPsec.

Now consider step 1 of the DH negotiation: “Alice and Bob agree to use a known prime number p and base g”. The values of p and g are selected from a pool of well known numbers which we refer to as Diffie-Hellman Groups. IANA has defined these groups here:

For example Group 2 uses the following well known numbers:
   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
   Its hexadecimal value is

         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
         EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381

   The generator is 2 (decimal)

Current best practices say to avoid IKE Groups 1, 2, and 5 and use IKE Group 14 or 24, both of which employ 2048-bit DH.

Encryption comes in two flavours DES or AES. The only other option is then the key length used for the encryption.

Key Length
Block Size

64 Bit
3DES (DES applied three times)
56*3=168 but really ~112 as its not perfect
64 Bit
128 Bit
128 Bit
128 Bit

However, you may encounter some security issues depending on the block size and how much data has to be encrypted. 3DES uses 64-bit blocks, which can lead to trouble after processing 2^(64/2) blocks, i.e. 32 gigabytes; AES uses 128-bit blocks, for a limit of 2^(128/2) blocks, i.e. 2^68 bytes, also known as "quite a lot of data". 2^68 bytes of data is approximately 20 times the information content of "all human knowledge."

What this really means is if you choose 3DES for your encryption and happen to transmit >32 gigabits of data then your DH key could be extracted. If the keys are never changed, an eavesdropper is listening in on an IPsec session could be easily compromised.

By setting up a lifetime (of time for IKE phase 1, and Time and/or Data for IKE phase 2) we cause the tunnels to be torn down and recreated periodically which reduces the amount of time the attacker would have to decode and take advantage of our tunnels.

IKE phase 2 doesn't run DH again (since it was run during IKE phase 1 to generate shared secret keys for both peers). So if the Phase 1 key is compromised then the Phase 2 negotiation can viewed. However, if IKE phase 2 doesn't want to use the keys created in IKE phase 1 there is an option to run DH again in IKE phase 2.  This 2nd DH is called PFS (Perfect Forward Secrecy) and if desired the configuration could add the set pfs xxxx command in the crypto map to implement the PFS.

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 use.


No comments:

Post a Comment