1. Information Security 2 (InfSi2)
4.6 Internet Key Exchange IKE
Prof. Dr. Andreas Steffen Institute for Internet Technologies and Applications (ITA)
4 Virtual Private Networks
4.6 Internet Key Exchange (IKE)
• Security association (SA) • IKE phase 1 - main mode • IKE phase 1 - aggressive mode • Man-in-the-middle attacks on aggressive mode • IPsec ID types • ISAKMP and IPsec security associations • IKE phase 2 – quick mode • Perfect forward secrecy (PFS) • IPsec configuration example • The new standard – IKEv • IKE_SA_INIT / IKE_AUTH request/response pairs • CREATE_CHILD_SA request/response pair
4.7 VPN Applications
• Site-to-site and remote access tunnels • Windows 7 / Linux strongSwan VPN clients
4.8 VPN Features
• Extended authentication (XAUTH / EAP) • Configuration payload • NAT traversal (ESP-in-UDP encapsulation) • Dead peer detection

2. IPsec – Automatic Key Management The Internet Key Exchange (IKE)
Security Association (SA)
A Security Association is a contract established between two IPsec endpoints (hosts or security gateways).
Negotiation of parameters to be used for the IPsec connection.
ISAKMP SA (IKEv1) or IKE SA (IKEv2) protects the IKE negotiation.
Separate IPsec SA required for each subnet or single host.
Separate IPsec SA required for inbound and outbound connection.
IPsec SAs are assigned a unique Security Parameters Index (SPI) and are maintained in a database.
Negotiated Parameters
Authentication Mechanism (IKEv1 only, pre-shared key or public key)
Encryption algorithm, Hash algorithm, PRF
Key exchange using Diffie-Hellman groups
Key lifetimes (IKEv1 only) for the ISAKMP and IPsec SAs.

3. Internet Key Exchange – IKEv1 Main Mode
Responder
Initiator
UDP/500
IKE Header
ISAKMP SA Proposal 1
IKE Header
ISAKMP SA Response 2 3
IKE Header
DH Key Exchange Ni
IKE Header
DH Key Exchange Nr 4 5
IKE Header
encrypted
IDi
Certi
Sigi
encrypted
IKE Header 6
IDr
Certr
Sigr
IKEv1 Quick Mode – another three messages to negotiate traffic selectors

4. IKE Main Mode using Pre-Shared Keys
Responder
Initiator
UDP/500
IKE Header
ISAKMP SA Proposal 1
IKE Header
ISAKMP SA Response 2 3
IKE Header
DH Key Exchange Ni
IKE Header
DH Key Exchange Nr 4 5
IKE Header
encrypted
IDi
Hashi
encrypted
IKE Header 6
IDr
Hashr
Pre-shared key ● is worked into Hash ● is part of the IKE session key

5. IKE Aggressive Mode using PreShared Keys
Initiator
UDP/500
Responder
IKE Header
ISAKMP SA Proposal 1
DH Key Exchange Ni
IDi
IKE Header
ISAKMP SA Response 2
DH Key Exchange Nr
IDr
Hashr 3
Hashi
Unencrypted IKE Aggressive Mode messages carrying cleartext IDs can be easily sniffed by a passive attacker.
Pre-Shared Key is worked into Hashr , together with other known parameters, so that an off-line cracking attack becomes possible.

6. Man-in-the-Middle Attack possible with IKE Aggressive Mode and XAUTH
Wireless LAN User
VPN Client 1
Group Password
Attacker
Man-in-the-Middle 2
bodo
aznHu4Um
XAUTH
Group Password
Username:
Password:
bodo
aznHu4Um
XAUTH
VPN Gateway
WLAN Access Point
With IKE Aggressive Mode, use One-Time Password scheme (e.g. SecureID).

7. ISAKMP and IPsec Security Associations
09:00
#1 ISAKMP SA
09:00
#2 IPsec SA
rightsubnet= /22
09:10
#3 IPsec SA
rightsubnet= /24
#4 IPsec SA
09:50
rightsubnet= /22
10:05
#5 IPsec SA
rightsubnet= /24
10:50
#6 IPsec SA
ikelifetime=3h keylife=1h
11:00
#7 IPsec SA
11:40
#8 ISAKMP SA 9 10 11 12

8. IKE Phase 2 – Quick Mode Establish or Renew an IPsec SA
Negotiation of IPsec Parameters
Phase 2 Quick Mode establishes an IPsec SA using the secure channel created by the phase 1 ISAKMP SA.
The specific configuration parameters for the IPsec connection are negotiated (AH, ESP, authentication / encryption methods and parameters).
Quick Mode can be used to renew IPSec SAs about to expire.
ESP/AH Key Derivation
The ESP encryption and ESP/AH authentication keys for the IPsec SAs are derived from the Phase 1 Diffie-Hellman secret.
Optional Perfect Forward Secrecy
If perfect forward secrecy is required, each consecutive Quick Mode will do a fresh Diffie-Hellmann key-exchange.

9. The New Standard - IKEv2 RFC 4306 (Dec. 2005) / RFC 5996 (Sep. 2010)
Motivation for a new IKE RFC
IKEv1 is spread over three documents (RFCs 2407, 2408, and 2409)
Too many messages (6 in Main Mode plus 3 in Quick Mode)
Too many variants (AH/ESP, transport/tunnel, authentication modes)
Too complex – therefore potentially insecure (Bruce Schneier)
Cookies not required when not under DoS attack
New features: NAT-T, Dead Peer Detection, etc.
IKEv2 Protocol
IPsec SA can be established with 2 request/response pairs
Additional Child SAs require one request/response pair, each
EAP authentication modes supported (e.g. One-Time-Passwords), replaces proprietary XAUTH
New IKE configuration payload replaces proprietary Mode Config
IKEv2 is not backwards compatible with IKEv1 !!!

10. IKEv2 – Authentication and first Child SA
Responder
Initiator
UDP/500
IKE Header 1
SA1i
KEi Ni 2
IKE Header
SA1r
KEr Nr
IKE_SA_INIT exchange pair 3
IKE Header
encrypted
IDi
Certi
Authi
IDr
SA2i
TSi
TSr
SA1i Suite of cryptographic proposals for the IKE SA
KEi Initiatior public factor for the Diffie-Hellman Key Exchange
Ni Initiator Nonce
SA1r Selection of a cryptographic proposal for the IKE SA
KEr Responder public factor for the Diffie-Hellman Key Exchange
Nr Responder Nonce
IDi Initiator ID
Certi Initiator Certificate (optional)
IDr Desired Responder ID (optional)
Authi Initiator Authentication (RSA, PSK, or EAP)
SA2i Suite of cryptographic proposals for the Child SA (ESP and/or AH)
TSi Initiator Traffic Selectors (subnets behind the Initiator)
TSr Responder Traffic Selectors (subnets behind the Responder)
IDr Responder ID
Certr Responder Certificate (optional)
Authr Responder Authentication (RSA, PSK, or EAP)
SA2r Selection of a cryptographic proposal for the Child SA (ESP and/or AH)
TSi Initiator Traffic Selectors (subnets behind the Initiator, optional narrowing)
TSr Responder Traffic Selectors (subnets behind the Responder, optional narrowing) 4
encrypted
IKE Header
IDr
Certr
Authr
SA2r
TSi
TSr
IKE_AUTH exchange pair

11. Cookie Mechanism against DoS Attacks
Responder
Initiator
UDP/500
IKE Header 1
SA1i
KEi Ni 2
IKE Header
N(COOKIE)
IKE Header 3
N(COOKIE)
SA1i
KEi Ni 4
IKE Header
SA1r
KEr Nr
# strongswan.conf
charon { dos_protection = yes cookie_threshold = block_threshold = 5 }

12. IKEv2 – Additional Child SAs
Responder
Initiator
UDP/500 1
IKE Header
encrypted N
SAi Ni
KEi
TSi
TSr 2
IKE Header
encrypted
SAr Nr
KEr
TSi
TSr
CREATE_CHILD_SA exchange pair
Rekeying IKE_SA: { SAi, Ni, KEi }
Rekeying CHILD_SA: { N(REKEY_SA), SAi, Ni, [KEi], TSi, TSr }
Reauthentication: Start with IKE_SA from scratch
N Rekeying Notification (optional)
SAi Suite of cryptographic proposals for the Child SA (ESP and/or AH)
Ni Initiator Nonce
KEi Initiatior public factor for the Diffie-Hellman Key Exchange (optional PFS)
TSi Initiator Traffic Selectors (subnets behind the Initiator)
TSr Responder Traffic Selectors (subnets behind the Responder
SA1r Selection of a cryptographic proposal for the IKE SA
Nr Responder Nonce
KEr Responder public factor for the Diffie-Hellman Key Exchange (optional PFS)

13. IKEv2 Remote Access Scenario
#ipsec.secrets for roadwarrior carol
: RSA carolKey.pem "nH5ZQEWtku0RJEZ6"
#ipsec.secrets for gateway moon
: RSA moonKey.pem
#ipsec.conf for roadwarrior carol
conn home
keyexchange=ikev2
left=%any
leftsourceip=%config
leftcert=carolCert.pem
leftfirewall=yes
right=
rightsubnet= /16
auto=start
#ipsec.conf for gateway moon
conn rw
keyexchange=ikev2
left=%any leftsubnet= /24
leftcert=moonCert.pem
leftfirewall=yes
right=%any
rightsourceip= /24
auto=add

14. Information Security 2 (InfSi2)
4.7 VPN Applications

15. Virtual Private Networks
„Road Warrior“
VPN Client
55.66.x.x
Internet
VPN Tunnel
Head Quarters
VPN Tunnel
Subsidiary
/16
/16
VPN Gateway
VPN Gateway

16. The „Road Warrior“ Remote Access Case
Internet
Virtual IP
Home Network
IPsec Tunnel
55.66.x.x
Dynamic IP
/16
VPN Gateway
Road Warrior
Road Warrior sign on to their home network via IKE with varying IP addresses assigned dynamically by the local ISP.
Authentication is usually based on RSA public keys and X.509 certificates issued by the home network.
Virtual IP assigned statically or dynamically by the home network. Remote hosts thus become part of an extruded net.

17. Windows 7 Agile VPN Client
Gateway certificate must contain host name [or IP address] and the serverAuth extendedKeyUsage flag.

18. strongSwan Applet for the Linux Desktop
D-Bus based communication between NetworkManager and strongSwan daemon.
If a CA root certificate is specified then the hostname [or IP address] of the VPN gateway must be contained as a subjectAltName in the received gateway certificate.

19. strongSwan in a Mixed VPN Environment
Windows Active Directory Server
Linux FreeRadius Server
Campus Network
High-Availability strongSwan VPN Gateway
N Rekeying Notification (optional)
SAi Suite of cryptographic proposals for the Child SA (ESP and/or AH)
Ni Initiator Nonce
KEi Initiatior public factor for the Diffie-Hellman Key Exchange (optional PFS)
TSi Initiator Traffic Selectors (subnets behind the Initiator)
TSr Responder Traffic Selectors (subnets behind the Responder
SA1r Selection of a cryptographic proposal for the IKE SA
Nr Responder Nonce
KEr Responder public factor for the Diffie-Hellman Key Exchange (optional PFS)
Internet
Windows 7/8 Agile VPN Client
strongSwan Linux Client
strongswan.hsr.ch

20. Information Security 2 (InfSi2)
4.8 VPN Features

21. Extended Authentication
IKEv1 - XAUTH (eXtended AUTHentication)
Proprietary extension used by many vendors (Cisco, Checkpoint, etc.)
Based on expired draft-beaulieu-ike-xauth-02.txt
IKEv2 - EAP (Extensible Authentication Protocol)
EAP-AKA, EAP-SIM, EAP-MSCHAPv2, EAP-MD5, EAP-GTC, EAP-TLS, etc.
VPN client triggers EAP by omitting AUTH payload
VPN gateway must send public key AUTH payload first!
VPN gateway relays authentication messages to and from AAA server (RADIUS, DIAMETER or LDAP)
IKE messages
AAA Server
VPN Client
VPN Gateway

22. Configuration Payload
IKEv1 – Mode Config Payload
Proprietary extension used by many vendors (Cisco, Checkpoint, etc.)
Based on expired draft draft-dukes-ike-mode-cfg-02.txt
IKEv2 – Configuration Paiload
has official CP payload
VPN gateway fetches configuration attributes from AAA server
Virtual IPv4 or IPv6 address
Internal DNS and WINS servers
Proprietary attributes (Cisco Unity, Microsoft, 3GPP, etc.)
IKE messages
AAA Server
VPN Client

23. IPsec Passthrough (Transparent IPsec Connection)
ESP and IKE from a single VPN client
UDP/500
55.66.x.x UDP/500
ESP
55.66.x.x ESP
UDP/500
ESP
ADSL and Cable routers use Network Address Translation (NAT) to connect one or several hosts sitting behind the router access to the Internet.
IPsec passthrough forwards ESP und IKE packets to a preconfigured host behind the NAT router.
Drawback: Each router model is configured differently, causing exorbitant costs supporting individual users.

24. NAT-Traversal (UDP encapsulation of ESP packets)
ESP and IKE from several VPN clients
UDP/4500
55.66.x.x UDP/1026
UDP/4500
55.66.x.x UDP/1025
UDP/4500
NAT-Traversal is used if several VPN clients want to set up secure tunnels through a common router doing NAT.
Typical Applications: WLAN hotspots, hotels, conferences, mobility via GSM/GPRS.
NAT-Traversal facilitates remote access e.g. working at home.

25. ESP-in-UDP Encapsulation (RFC 3948)
UDP-Encapsulated ESP Header Format
Src Port (4500)
Dst Port (4500)
UDP Header
Length
Checksum
Security Parameters Index
ESP Header
IKE Header Format for Port 4500
Src Port (4500)
Dst Port (4500)
UDP Header
Length
Checksum
0x00
0x00
0x00
0x00
Non-ESP Marker
IKE Header
IKE Header
NAT-Keepalive Packet Format
Src Port (4500)
Dst Port (4500)
UDP Header
Length
Checksum
0xFF
Keepalive Payload

26. IKEv2 Dead Peer Detection
#ipsec.conf for roadwarrior carol
conn %default
dpddelay=60
dpdaction=restart
#ipsec.conf for gateway moon
conn %default
dpddelay=60
dpdaction=clear
Oct 24 11:45:10 13[IKE] CHILD_SA home{1} established with SPIs c50810d9_i c8485f4a_o
Oct 24 11:46:10 16[NET] received packet: from [500] to [500]
Oct 24 11:46:10 16[ENC] parsed INFORMATIONAL request 0 [ ]
Oct 24 11:46:10 16[ENC] generating INFORMATIONAL response 0 [ ]
Oct 24 11:46:10 16[NET] sending packet: from [500] to [500]
Oct 24 11:47:09 09[IKE] sending DPD request
Oct 24 11:47:09 09[ENC] generating INFORMATIONAL request 2 [ ]
Oct 24 11:47:09 09[NET] sending packet: from [500] to [500]
Oct 24 11:47:13 03[IKE] retransmit 1 of request with message ID 2
Oct 24 11:47:13 03[NET] sending packet: from [500] to [500]
Oct 24 11:47:20 11[IKE] retransmit 2 of request with message ID 2
Oct 24 11:47:20 11[NET] sending packet: from [500] to [500]
Oct 24 11:47:33 08[IKE] retransmit 3 of request with message ID 2
Oct 24 11:47:33 08[NET] sending packet: from [500] to [500]
Oct 24 11:47:56 12[IKE] retransmit 4 of request with message ID 2
Oct 24 11:47:56 12[NET] sending packet: from [500] to [500]
Oct 24 11:48:38 14[IKE] retransmit 5 of request with message ID 2
Oct 24 11:48:38 14[NET] sending packet: from [500] to [500]
Oct 24 11:49:54 16[IKE] giving up after 5 retransmits
Oct 24 11:49:54 16[IKE] restarting CHILD_SA home
Oct 24 11:49:54 16[IKE] initiating IKE_SA home[2] to
Dead Peer Detection
• If Dead Peer Detection (DPD) is activated then the peer is polled every dpddelay seconds by sending an IKEv2 INFORMATIONAL request message if no inbound ESP or IKE activity was detected during the previous dpddelay interval. Typical values for dpddelay are seconds but if the IKEv2 Mobility and Multihoming (MOBIKE) protocol is used where quite some time can elapse until a new network interface appears then dpddelay should be increased to 5 minutes.
• If no matching IKEv2 INFORMATIONAL response is received, the regular retransmission scheme for IKEv2 packets is applied and if still no response arrives after about 5 retries over 2-3 minutes, the peer is declared dead and the IKE SA and all attached all CHILD SAs are deleted.