CSE 4905 IPsec II

Recall IPsec SA Two entities need to establish Security Associations SA for communication from A to B includes a collection of attributes Security Parameter Index (SPI) Encryption key Encryption algorithm Authentication key Authentication algorithm

Key management for IPsec establishing and maintaining SAs between pairs of communicating entities Internet Key Exchange (IKE) Exchange and negotiate security policies Establish security associations Key exchange Key management Typical implementation IKE daemon in user space IPsec stack in kernel space (for efficiency)

IKE history IETF defined IKE in November 1998 IKE v2 RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP RFC 2408: The Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409: The Internet Key Exchange (IKE) ISAKMP: gift to IETF from NSA Total: 150 pages, complex & confusing IKE v2 A few versions starting from December 2005 Current Internet standard: RFC 7296, October 2014

IKE: two phases Phase I: negotiate and establish an auxiliary end-to-end secure channel Used by subsequent phase II negotiations Only established once between two end points! Also called IKE-SA phase Phase II: negotiate and establish custom secure channels Can occur multiple times Also called IPsec-SA phase Through UDP, port 500 Initiator responsible for retransmissions

Discussion: why two phases in IKE? Not an obvious need for two phases Only beneficial if multiple Phase 2’s occur

IKE Phase 1 Goal: to establish a secure channel between two end points w/ security features: Source authentication Data integrity and data confidentiality Protection against replay attacks Rationale each application has different security requirements But they all need to negotiate policies and exchange keys! So, provide the basic security features and allow application to establish custom sessions

Examples All packets sent to address mybank.com must be encrypted using 3DES with HMAC-MD5 integrity check All packets sent to address www.forum.com must use integrity check with HMAC-SHA1 (no encryption is required)

Phase 1 protocols Four different “key” options Two modes Public key encryption (original version) Public key encryption (improved version) Public key signature Pre-shared symmetric key Two modes Main mode (6 messages) Aggressive mode (3 messages) There are 8 versions of IKE Phase 1!

Discussion: why three types of “key” options? Pre-shared keys: OK for small-scale settings, better efficiency Why public key signature vs public key encryption?

Phase 1 exchange: two modes Main mode Six messages in three round trips More options Aggressive mode Three messages in two round trips Less options Both modes use Diffie-Hellman key exchange to establish a shared key

Phase 1 aggressive mode 3 messages The first two messages: negotiate policy, exchange Diffie-Hellman public values and ancillary data and identities In addition, the second message authenticates the responder The third message: authenticates the initiator

General Idea of Aggressive Mode Alice Bob I’m Alice, gA mod p, nonceA I’m Bob, gB mod p, proof I’m Bob, nonceB proof I’m Alice Bob either accepts g and p from A or fail Proof of identity: prove sender knows the secret key associated with the identity; integrity protection of previous messages

Phase 1 main mode 6 messages 1st two messages: negotiate policy 2nd two messages: exchange Diffie-Hellman public values and ancillary data (e.g., nonces) 3rd two messages: authenticate the Diffie-Hellman Exchange

General Idea of Main Mode Alice Bob crypto suites I support crypto suites I choose gA mod p, nonceA gB mod p, nonceB {“Alice”, proof I’m Alice} key variant-dependent {“Bob”, proof I’m Bob}

Main Mode: Preshared key S Alice Bob crypto suites I support crypto suites I choose gA mod p, nonceA gB mod p, nonceB {“Alice”, proof I’m Alice} f(S,gAB) {“Bob”, proof I’m Bob} f(S,gAB)

Phase 1 session keys Phase I establishes two session keys: Integrity key, encryption key Used to protect the last of phase I messages, and all phase II messages Basic procedure SKEYID: key seed obtained after DH, hash of nonces, DH values, etc. Exact method depends on “key” options Authentication key SKEYID_a from SKEYID Encryption key SKEYID_e from SKEYID

IKE Phase 2 Goal: to establish custom secure channels between two end points Use the secure channel established in Phase 1 for communication Only one mode: Quick Mode Generate SAs for two end points

General idea of Quick Mode IKE-SA, Y, {Ni, traffic, SPIA, [gA mod p]} IKE-SA, Y, {ack} IKE-SA, Y, {Nr, traffic, SPIB, [gB mod p]} Alice Bob New key is PRF(current key, gAB | Ni | Nr ) Ni: nonce from initiator Nr: nonce from responder Optional diffie-hellman Y: 32-bit number chosen by initiator DH optional {}: encrypted and integrity protected using keys from phase I

IKE v2 Not backward compatible Goal: Specify all functionalities in a single document Simplify and improve the protocol Fix various problems from deployment and analysis Not to make gratuitous changes to IKE v1

IPsec Policy Phase 1 policies Phase 2 policies defined as protection suites; each protection suite must contain: Encryption algorithm, Hash algorithm, Authentication method, Diffie-Hellman Group May optionally contain Lifetime, … Phase 2 policies defined as proposals each proposal may contain AH sub-proposals, ESP sub-proposals, IPComp sub-proposals Along with necessary attributes such as Key length, life time, …

IPSec Policy Example In English: In IPsec: All traffic to 128.104.120.0/24 must be: Use pre-hashed key authentication DH group is MODP with 1024-bit modulus Hash algorithm is HMAC-SHA (128 bit key) Encryption using 3DES In IPsec: [Auth=Pre-Hash; DH=MODP(1024-bit); HASH=HMAC-SHA; ENC=3DES]

IPsec Policy Example II In English: All traffic to 128.104.120.0/24 must use one of the following: AH with HMAC-SHA or, ESP with 3DES as encryption algorithm and (HMAC-MD5 or HMAC-SHA as hashing algorithm) In IPsec: [AH: HMAC-SHA] or, [ESP: (3DES and HMAC-MD5) or (3DES and HMAC-SHA)]

IPsec summary Security protocol for IP-layer security Between two entities Host-to-host, host-to-router, router-to-router AH and ESP protocols Transport and Tunnel mode Security association (SA) IPsec datagram Internet Key Exchange (IKE) Best use case: VPN