Advanced IKEv2 Protocol Jay Young, CCIE - Technical Leader, Services Session: BRKSEC-3001
Agenda IP Security overview IKEv1 Protocol Overview IKEv1 Everything is good, right? IKEv2 Overview Summary
IP Security Overview
or at least back to 1998 A need for a standard secure method to communicate over the Internet Architecture needed: Multiple Strong Authentication Methods Anti-clogging (DoS) Prevent Connection Hijacking Linking key exchange with authentication Prevent Man-in-the-middle attacks Interception, insertion, deletion, replay, redirection Encryption Integrity
IP security overview A collection of 12 RFCs published to define IP Security (IPsec) Some were very high level architectural designs Some were very low on roles, responsibilities and functions Numerous other RFCs defined to add shortcomings
IP Security Overview Cipher/Hash Key Exchange RFC2412 OAKLEY RFC2408 ISAKMP Architecture RFC2401 Sec Arch for IP RFC2411 IPsec Doc RFC2403 HMAC-MD5 RFC2404 HMAC-SHA-1 RFC2405 ESP w/ DES RFC2410 ESP-NULL Traffic Encapsulation Protocols RFC2406 ESP RFC2402 AH RFC2407 IPsec DOI Protocol Definition RFC2409 IKEv1 +many more minor additions NAT-T RFC3947+3948
ISAKMP ISAKMP defines two phases: Phase 1 Used for control plane Establish secure channel between peers Prove identities Negotiate data plane security settings Phase 2 Used for data plane Transports the protected data
IKEv1 Protocol Overview
IKEv1 There are two different modes for building Phase 1 Main Mode 6 packet exchange Full Identity protection Better Anti-DoS protection Aggressive Mode 3 packet exchange Identities passed in the clear Responder must authenticate himself first PSK can be retrieved by an offline brute-force attack Trivial to DoS Faster session establishment
IKEv1- Main Mode (message 1 and 2) The first two messages are used to negotiate the following cryptographic attributes: Authentication method* Encryption cipher* Integrity hash* Lifetime of Security Association Diffie-Hellman Key Exchange Group * Initiator proposes a list of combinations of the starred (*) above Responder picks one of the combinations proposed Lifetime is MIN(initiator, responder) NOT encrypted Peer NOT authenticated yet
IKEv1- Main Mode (MM1) Initiator HDR cookie: initiator = X (randomly generated number per session) responder = 00000000, SA (multiple crypto policies), Vendor IDs String or hash value. Used to advertise support for capabilities not defined in standard (i.e. NAT-T) Responder MM1 Unencrypted Unauthenticated Reference
IKEv1- Main Mode (MM2) Initiator HDR cookie: initiator = X (retained) responder = Y (randomly generated per session), SA (the selected crypto policy), Vendor IDs String or hash value. Used to advertise support for capabilities not defined in standard (i.e. NAT-T) Responder MM2 Unencrypted Unauthenticated Reference
IKEv1- Main Mode (message 3 and 4) Exchange Diffie-Hellman key values Exchange Nonce values Detect if NAT is used between peers Suggest trusted certificate authorities (CA) After this exchange, further communication is encrypted and secure. Peer NOT authenticated yet.
IKEv1- Main Mode (MM3) Initiator HDR (cookie i=x,r=y) Diffie-Hellman Key Exchange material (g^xi) Nonce from initiator (random data [entropy + anti-replay]) Additional Vendor IDs NAT-Discovery Payloads Responder MM3 Unencrypted Unauthenticated Reference
IKEv1- Main Mode (MM4) Initiator HDR (cookie i=x,r=y) Diffie-Hellman Key Exchange material (g^xr) Nonce from responder (random data [entropy + anti-replay]) Additional Vendor IDs NAT-Discovery Payloads [Certificate Request] Hints of which CAs the responder trusts Responder MM2 Unencrypted Unauthenticated Reference
Diffie-Hellman Groups Number Name 1 Group 1-768-bit MODP Group 2 Group 2-1024-bit MODP Group 5 1536-bit MODP Group 14 2048-bit MODP Group 15 3072-bit MODP Group 16 4096-bit MODP Group 17 6144-bit MODP Group 18 8192-bit MODP Group 19 256-bit random ECP group 20 384-bit random ECP group 21 521-bit random ECP group 22 1024-bit MODP Group with 160-bit Prime Order Subgroup 23 2048-bit MODP Group with 224-bit Prime Order Subgroup 24 2048-bit MODP Group with 256-bit Prime Order Subgroup 25 192-bit Random ECP Group 26 224-bit Random ECP Group Reference
Diffie-Hellman Primer p=23 g=5 p and g are constants defined by DH Group Alice a=6 g^a mod p = A = 5^6 mod 23 = 15,625 mod 23 = 8 g^b mod p = A = 5^15 mod 23 = 30,517,578,125 mod 23 = 19 Alice b=15 s = B^a mod p s = 19^6 mod 23 s = 47,045,881 mod 23 s = 2 A^b mod p = s 8^15 mod 23 = s 35,184,372,088,832 mod 23 = s 2 = s Reference
IKEv1- KEYS From the derived secret value a SKEYID is created using values from the ISAKMP exchange. Provides protection against replay attacks using the same DH values. Different SKEYID generation based on authentication type: Pre-shared-key: SKEYID = prf(pre-shared-key, Ni_b Nr_b) Signatures (Certs): SKEYID = prf(ni_b Nr_b, g^xy) Then from that SKEYID three sub-keys are created: SKEYID_d = prf(skeyid, g^xy CKY-I CKY-R 0) - For further keying material derivation SKEYID_a = prf(skeyid, SKEYID_d g^xy CKY-I CKY-R 1) - Authentication Key SKEYID_e = prf(skeyid, SKEYID_a g^xy CKY-I CKY-R 2) - Encryption Key Reference
IKEv1- Main Mode (message 5 and 6) Exchange certificate Prove identity using Pre-Shared Key or Certificate Cryptographically validate previous messages prevents session hijack Switched to UDP/4500 if NAT had been detected in MM3+4 Encrypted Peer is proving identity.
IKEv1- Main Mode (MM5) Initiator HDR (cookie i=x,r=y) Identity (a string value representing who I am) Auth payload (cryptographic proof-of-possession built from preshared-key or digital signature) [Initial Connect] Optional payload to help synchronize SAs [Certificate] Copy of initiator s ID cert + chain [Certificate Request] Hints of which CAs the initiator trusts Responder MM5 Encrypted Initiator: Proving identity Responder: Unauthenticated Reference
IKEv1- Main Mode (MM6) Initiator HDR (cookie i=x,r=y) Identity (a string value representing who I am) Auth payload (cryptographic proof-of-posession built from preshared-key or digital signature) [Certificate] Copy of responder s ID cert + chain Responder MM6 Encrypted Initiator: Authenticated Responder: Proving identity Reference
Encrypted but Unauthenticated Unencrypted + Unauthenticated IKEv1 Main Mode Summary Initiator Responder MM1 (HDR, SA, VID) MM2 (HDR, SA, VID) Negotiate crypto settings MM3 (HDR, Nonce, KE, VID) MM4 (HDR, Nonce, KE, VID, [CERT-REQ]) Secret key exchange MM5 (HDR, IDi, AUTH, [IC], [CERT],[CERT-REQ]) MM6 (HDR, IDr, AUTH, [CERT]) Prove identity Phase 1 complete Encrypted & Authenticated
Encrypted + Authenticated Unencrypted but Responder Authenticated Unencrypted + Unauthenticated IKEv1 Aggressive Mode Summary Initiator AM1 (HDR, SA, KE, Nonce, IDi, VID) Responder Negotiate crypto settings + 1 st ½ of key exchange AM2 (HDR, SA, KE, Nonce, VID, IDr, AUTH ) AUTH payload hashed using portions of AM1+2 and derived SKEYID_a Negotiate crypto settings + 2 st ½ of key exchange + responder proves identity AM3 (HDR, IDi, AUTH) Phase 1 complete Encrypted & Authenticated Initiator proves identity
IKEv1 Phase 1 1 st Phase is already built: it provides security and proof with whom you are communicating with The following operations occur over this Phase 1 SA: Dead Peer Detections (keepalive messages) Negotiation and Establishment of ESP and AH SAs (Phase 2) Notifications Xauth (Username/Password Authentication) Remote access Mode_CFG (IP address assignment, DNS, etc.) Remote access In most deployments Phase 2 is IPsec, but other DOIs exist (e.g. GDOI).
IKEv1 Quick Mode Phase 2 Quick mode allows the establishment of an IPsec SA in three messages Things negotiated: Traffic to be protected How to be encapsulated How to be encrypted How to provide integrity How long the SA is valid for in time and volume of data If Perfect Forward Secrecy (PFS) is required
IKEv1- Quick Mode (QM1) Initiator Responder HASH(1) SA (Transform sets, SPI) Nonce (for replay protection) [Key Exchange] (if PFS is desired) Proposed Traffic Selectors NAT address information QM1 Reference
IKEv1- Quick Mode (QM2) Initiator Responder HASH(2) SA (Transform set, SPI) Nonce (for replay protection) [Key Exchange] (if PFS is desired) Selected Traffic Selectors NAT address information QM2 Reference
IKEv1- Quick Mode (QM3) Initiator Responder HASH(3) Essentially just an ACK QM3 Reference
IKEv1- Quick Mode Summary Initiator SA (Transform sets, SPI) Nonce (for replay protection) [Key Exchange] (if PFS is desired) Proposed Traffic Selectors NAT address information Responder QM1 - Request QM2 Yes or No Just an ACK QM3
IKEv1 Everything s good, right?
IKEv1 Challenges NAT Traversal (NAT-T) Certificates (hints) Pre-shared-keys with identities Hello are you there or just don t have anything to say?
IKEv1 NAT-T IPsec uses IP protocol 50 (ESP) and 51 (AH) AH can t work through NAT ESP can work through 1:1 NAT Most NAT devices do 1-to-many Port Address Translation (PAT) Rule of Thumb Only TCP and UDP can reliably transported over Internet ESP doesn t have ports ESP can t work through PAT Solution: Encapsulate ESP packets within UDP
IKEv1 NAT-T Solution: Encapsulate ESP packets within UDP when going through NAT NAT/PAT devices only see UDP packets. Port 4500 is reserved for IPsec over UDP Both IKE and ESP SA use UDP/4500. Support for NAT-T was added with RFC 3947 and 3948
IKEv1 Determine if NAT is in path IP Addr: A NAT device A->C IP Addr: B MM1 VID (I can do NAT-T) IP A->B Port 500->500 MM2 VID (I can do NAT-T) IP B->A Port 500->500 MM1 VID (I can do NAT-T) IP C->B Port 1434->500 MM2 VID (I can do NAT-T) IP B->C Port 500->1434 Advertise NAT-T support Initiator computes hashes and includes them inside packet Hash(IP A + Port 500) Responder computes + compares hashes against ones inside packet Hash(IP B + Port 500) Hash(IP C + Port 1434) Hash(IP B + Port 500) Initiator Hash different -> behind NAT MM3 VID IP A->B Port 500->500 MM3 VID IP C->B Port 1434->500 Responder Hash same -> not behind NAT
IKEv1 Determine if NAT is in path Initiator Hash different -> behind NAT IP Addr: A Initiator computes + compares hashes against ones inside packet Hash(IP A + Port 500) Hash(IP B + Port 500) NAT device A->C Responder computes hashes and includes them inside packet Hash(IP C + Port 1434) Hash(IP B + Port 500) IP Addr: B Responder Hash same -> not behind NAT MM4 IP B->A Port 500->500 MM4 IP B->C Port 500->1434 Both Initiator and Responder both know who is behind NAT Switch to UDP/4500 MM5 - IP A->B Port 4500->4500 MM5 - IP C->B Port 6234->4500 MM6 IP B->A Port 4500->4500 MM6 IP B->C Port 4500->6234
IKEv1 NAT-T IP Addr: A NAT device A->C IP Addr: B Data Traffic ESP Payload IP A->B UDP Port 4500->4500 ESP Payload IP C->B UDP Port 6234->4500 ESP Payload Control Traffic 0000 + IKE Message IP A->B UDP Port 4500->4500 0000 + IKE Message IP C->B UDP Port 6234->4500 0000 + IKE Message
IKEv1 Certificates Authentication can use certificates Problem 1: Peer must know which CAs are trusted by peer Explicit configuration doesn t scale Solution 1: RFC4945 Prior to AUTH provide a list of trusted CAs to peer In MM4 Responder sends list of CA he trusts In MM5 Initiator sends list of CA he trusts.
IKEv1 Certificates CA4 CA2 CA5 ID4 ID2 Subject Subject Subject Initiator MM4 (HDR, Nonce, KE, VID, [CERT-REQ]) Responder CA1 CA2 CA3 MM5 (HDR, IDi, AUTH, [IC], [CERT],[CERT-REQ])
IKEv1 Pre-shared-keys Keys are linked to an identity IP address, FQDN, Email, Distinguished Name Identities are shared in MM5 and MM6 The PSK is part of key generation Crypto keys are generated in MM3 and MM4 PSK lookup can ONLY be done on IP address If remote devices have dynamic addresses, then use wildcard key (not best practice) Workaround: Use Aggressive mode Caveat: Aggressive mode is less secure?
IKEv1 Dead Peer Detection Problem: We haven t received any packet from our peer. Is he dead or just nothing to say? Solution: RFC 3706 - Send a message asking if he is alive Peer1 Peer2 Notify(R-U-THERE) Notify(R-U-THERE-ACK)
IKEv2 Overview (Finally!)
IKEv2 Goals (What did we learn) Define IKEv2 in one document rather than a combination of many Reduce setup latency by reducing number of messages More secure Always provide identity protection (No Aggressive mode) PSK is not used in crypto key generation Provide additional authentication mechanisms (EAP) Allow more flexible authentication choices (asymmetrical) Exchange of routes and attributes Reduce number of options/methods simplify implementations
Encrypted but Unauthenticated Unencrypted + Unauthenticated IKEv2 Session Establishment Overview Initiator Responder IKE_SA_INIT Req (HDR, SA, VID, KE, Nonce, NAT-D) IKE_SA_INIT Res (HDR, SA, VID, KE, Nonce, NAT-D, [CERT-REQ]) Negotiate crypto settings, secret key exchange, NAT detection IKE_AUTH (HDR, IDi, AUTH, CREATE_CHILD_SA, N(IC), [CERT],[CERT-REQ]) IKE_AUTH (HDR, IDr, AUTH, CREATE_CHILD_SA, [CERT]) Prove identity and create phase 2 SA Phase 1 complete Encrypted & Authenticated
IKEv2 CREATE_CHILD_SA For additional IPsec SAs or Phase-1 Rekey Everything within SK is encrypted and authenticated Peer1 Peer2 CREATE_CHILD_SA (HDR, SK {SA, Ni, [KEi,], TSi, TSr} ) CREATE_CHILD_SA (HDR, SK {SA, Nr, [KEr,] TSi, TSr} )
IKEv1 vs IKEv2 Session Establishment Overview MM1 (SA, VID) MM2 (SA, VID) IKE_SA_INIT Req MM3 (Nonce, KE, VID, NAT-D) MM4 (Nonce, KE, VID, NAT-D, [CERT-REQ]) IKE_SA_INIT Res MM5 (IDi, AUTH, [IC], [CERT],[CERT-REQ]) MM6 (IDr, AUTH, [CERT]) IKE_AUTH Req QM1 (SA, TS, [NAT-OA]) QM2 (SA, TS, [NAT-OA]) IKE_AUTH Res QM3
IKEv2 Faster exchange right? It depends! Exponentiation is done after 1 st packet Vulnerable to DOS spoofing attack! When IKEv2 *might* be under attack, add another exchange prior to exponentiation to confirm source reachability Generate a cheap stateless cookie hmmm Am I under attack? I n i t i a t o r IKE_SA_INIT Req (HDR, SA, VID, KE, Nonce, NAT-D) IKE_SA_INIT Res (HDR, N(COOKIE)) IKE_SA_INIT Req (HDR, SA, VID, KE, Nonce, NAT-D, N(COOKIE)) IKE_SA_INIT Res (HDR, SA, VID, KE, Nonce, NAT-D, [CERT-REQ]) copy + + =
IKEv2 Faster exchange right? Part 2 Key establishment is done in first two packets. Initiator must guess which DH group his peer will accept If wrong/unacceptable group is sent, responder will hint and say try again I n i t i a t o r IKE_SA_INIT Req (HDR, SA, VID, KE, Nonce, NAT-D) IKE_SA_INIT Res (HDR, N(INVALID_KE_PAYLOAD)) IKE_SA_INIT Req (HDR, SA, VID, KE, Nonce, NAT-D) IKE_SA_INIT Res (HDR, SA, VID, KE, Nonce, NAT-D, [CERT-REQ]) DH mismatch. Try again with group 14 OK good this time!
IKEv2 Faster exchange right? Part 3 EAP authentication of client EAP messages are carried within IKE_AUTH messages Adds multiple IKE exchanges back and forth between client and NAS N x exchanges Depends on EAP method
IKEv2 EAP Authentication EAP authentication of client. Adds N number of additional exchanges between peers I n i t i a t o r N times IKE_SA_INIT Req (HDR, SA, VID, KE, Nonce, NAT-D) IKE_SA_INIT Res (HDR, SA, VID, KE, Nonce, NAT-D, [CERT-REQ]) IKE_AUTH (HDR, IDi, CREATE_CHILD_SA, N(IC), [CERT],[CERT-REQ]) IKE_AUTH (HDR, IDr, AUTH, [CERT],EAP) IKE_AUTH (HDR, EAP) RADIUS AAA Server N times IKE_AUTH (HDR,EAP) IKE_AUTH (HDR, AUTH) IKE_AUTH (HDR,AUTH, CREATE_CHILD_SA )
IKEv2 Faster exchange right? Part 4 4 packets for basic exchange +2 for Anti-spoofing (if detected) +2 for incorrect DH group +(2 x N) exchanges for EAP Authentication
IKEv2 More Secure Reuses encapsulation model from ESP for all IKEv2 messages Certificate Request are obfuscated Support for combined mode ciphers (AEAD) EAP versus XAUTH No need for a group pre-shared-key NAS never sees user/password in clear Initiator must prove identity first (except w/ EAP) Suite-B support
IKEv2 Authentication Methods Unlike IKEv1, authentication is performed unidirectionally in IKEv2 Different pre-shared-keys can be used for local and remote Different authentication methods can be used for local and remote Example: Local can prove identity using a certificate Remote can prove identity using a pre-shared-key or EAP crypto ikev2 profile Profile1 match identity remote fqdn domain example.com identity local fqdn hub.example.com authentication remote pre-share authentication remote eap authentication local rsa-sig
IKEv2 Rekeys IKEv1 IKEv2 IPSec SAs can let parent Phase-1 expire. New Phase-1 setup when DPD or rekey needed IKEv2 always-on SA. If IKEv2 dies it deletes child IPSec SAs. Lifetimes are negotiated and tracked on both sides. Lifetimes are locally significant. Whichever peer s timer pops first sends a Delete for the SA Phase-1 rekey is a complete whole new handshake (forces re-authentication). Phase-1 rekey is handled in CREATE_CHILD_SA exchange (no re-authentication). RFC4478 Adds support for Re-authentication (no support in IOS yet)
IKEv2 Notifications/Deletes In IKEv1 Notifications are fire and forget Notifications are exchanges need to be ACKed Problem if peer has died! Need to wait until re-xmits complete before delete SA from DB
IKEv2 Attribute Exchange Config Request/Reply - Solicited Remote access use case: IP address DNS WINS Split-tunnel Config Set/Ack Unsolicited IKEv2 routing Version info Extensible for future
IKEv2 Fragmentation Large IKE messages make large UDP datagrams Packets get fragmented at IP layer Filtering/Blocking of fragments causes protocol failure Solution: Fragment at Application layer IKEv1 Proprietary, support only Cisco VPN client Encrypt then segment across multiple UDP packets IKEv2 Standard, RFC7883 Segment then encrypt
IKEv2 Simplified IOS implementation (FlexVPN) Smart defaults Tunnel Interface based Interoperability Unified configuration Simple configuration for basic topology Customizable for complex network requirements More explicit and easier to understand debugs Example: http://www.cisco.com/c/en/us/support/docs/security/flexvpn/115782-flexvpn-site-to-site-00.html
IKEv2 IOS configuration example interface Tunnel 10 ip address 172.16.1.1 255.255.255.252 ipv6 enable tunnel source Gig0/0 tunnel destination 192.168.1.1 tunnel protection ipsec profile Prof1 crypto ikev2 keyring Key1 peer RemoteRouter address 192.168.1.1 pre-shared-key Cisco123 crypto ipsec profile Prof1 set ikev2-profile ProfileA crypto ikev2 profile ProfileA match identity remote address 192.168.1.1 authentication remote pre-share authentication local pre-share keyring local Key1
Summary
Summary IKEv1 works well, but needed many add-ons to shine IKEv2 built those add-ons into standard IKEv2 easier to understand + troubleshoot IKEv2 has better security model + SuiteB support v1 and v2 are incompatible IOS (FlexVPN) simplifies configuration, allows vendor interoperability and highly scalable
Complete Your Online Session Evaluation Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card. Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect. Don t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online
Continue Your Education Demos in the Cisco Campus Walk-in Self-Paced Labs Table Topics Meet the Engineer 1:1 meetings
Thank you
Security Cisco Education Offerings Course Description Cisco Certification Implementing Cisco IOS Network Security (IINS) Implementing Cisco Edge Network Security Solutions (SENSS) Implementing Cisco Threat Control Solutions (SITCS) Implementing Cisco Secure Access Solutions (SISAS) Implementing Cisco Secure Mobility Solutions (SIMOS) Securing Cisco Networks with Threat Detection and Analysis (SCYBER) Network Security Product and Solutions Training Focuses on the design, implementation, and monitoring of a comprehensive security policy, using Cisco IOS security features Configure Cisco perimeter edge security solutions utilizing Cisco Switches, Cisco Routers, and Cisco Adaptive Security Appliance (ASA) Firewalls Deploy Cisco s Next Generation Firewall (NGFW) as well as Web Security, Email Security and Cloud Web Security Deploy Cisco s Identity Services Engine and 802.1X secure network access Protect data traversing a public or shared infrastructure such as the Internet by implementing and maintaining Cisco VPN solutions Designed for professional security analysts, the course covers essential areas of competency including event monitoring, security event/alarm/traffic analysis, and incident response For official product training on Cisco s latest security products, including Adaptive Security Appliances, NGIPS, Advanced Malware Protection, Identity Services Engine, Email and Web Security Appliances see www.cisco.com/go/securitytraining CCNA Security Cisco Cybersecurity Specialist For more details, please visit: http://learningnetwork.cisco.com Questions? Visit the Learning@Cisco Booth or contact ask-edu-pm-dcv@cisco.com