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 – IKEv2 • 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

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.

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

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

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.

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

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

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.

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 !!!

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

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 = 10 block_threshold = 5 }

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)

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 leftid=carol@strongswan.org leftfirewall=yes right=192.168.0.1 rightid=@moon.strongswan.org rightsubnet=10.1.0.0/16 auto=start #ipsec.conf for gateway moon conn rw keyexchange=ikev2 left=%any leftsubnet=10.1.0.0/24 leftcert=moonCert.pem leftid=@moon.strongswan.org leftfirewall=yes right=%any rightsourceip=10.3.0.0/24 auto=add

Information Security 2 (InfSi2) 4.7 VPN Applications

Virtual Private Networks „Road Warrior“ VPN Client 10.3.0.2 10.1.0.5 10.2.0.3 55.66.x.x Internet VPN Tunnel Head Quarters VPN Tunnel Subsidiary 10.1.0.0/16 10.2.0.0/16 VPN Gateway 11.22.33.44 VPN Gateway 55.66.77.88

The „Road Warrior“ Remote Access Case Internet Virtual IP 10.3.0.2 Home Network IPsec Tunnel 55.66.x.x Dynamic IP 10.1.0.0/16 VPN Gateway 11.22.33.44 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.

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

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.

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

Information Security 2 (InfSi2) 4.8 VPN Features

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

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

IPsec Passthrough (Transparent IPsec Connection) ESP and IKE from a single VPN client 10.3.0.2 UDP/500 55.66.x.x UDP/500 10.3.0.2 ESP 55.66.x.x ESP 11.22.33.44 UDP/500 11.22.33.44 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.

NAT-Traversal (UDP encapsulation of ESP packets) ESP and IKE from several VPN clients 10.3.0.3 UDP/4500 55.66.x.x UDP/1026 10.3.0.2 UDP/4500 55.66.x.x UDP/1025 11.22.33.44 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.

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

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 192.168.0.1[500] to 192.168.0.100[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.100[500] to 192.168.0.1[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 192.168.0.1 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 30-60 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.