IPSecAn Overview Somesh Jha University of Wisconsin 1

IPSec—An Overview Somesh Jha University of Wisconsin 1

Outline why IPSec? n IPSec Architecture n Internet Key Exchange (IKE) n IPSec Policy n discussion n 2

IP is not Secure! n IP protocol was designed in the late 70 s to early 80 s – Part of DARPA Internet Project – Very small network n All hosts are known! n So are the users! n Therefore, security was not an issue 3

Security Issues in IP source spoofing n replay packets n no data integrity or confidentiality n • DOS attacks • Replay attacks • Spying • and more… Fundamental Issue: Networks are not (and will never be) fully secure 4

Goals of IPSec n to verify sources of IP packets – authentication to prevent replaying of old packets n to protect integrity and/or confidentiality of packets n – Data Integrity/Data Encryption 5

Outline Why IPsec? n IPSec Architecture n Internet Key Exchange (IKE) n IPsec Policy n Discussion n 6

The IPSec Security Model Secure Insecure 7

IPSec Architecture ESP Encapsulating Security Payload AH Authentication Header IPSec Security Policy IKE The Internet Key Exchange 8

IPSec Architecture n IPSec provides security in three situations: – Host-to-host, host-to-gateway and gateway-to-gateway n IPSec operates in two modes: – Transport mode (for end-to-end) – Tunnel mode (for VPN) 9

IPsec Architecture Transport Mode Router Tunnel Mode 10

Various Packets Original IP header TCP header Transport mode IP header IPSec header TCP header IPSec header IP header Tunnel mode data TCP header data 11

IPSec n A collection of protocols (RFC 2401) – Authentication Header (AH) n RFC 2402 n RFC 2406 n RFC 2409 n RFC 3137 – Encapsulating Security Payload (ESP) – Internet Key Exchange (IKE) – IP Payload Compression (IPcomp) 12

Authentication Header (AH) n Provides source authentication – Protects against source spoofing n n Provides data integrity Protects against replay attacks – Use monotonically increasing sequence numbers – Protects against denial of service attacks n NO support for confidentiality! 13

AH Details Use 32 -bit monotonically increasing sequence number to avoid replay attacks n Use cryptographically strong hash algorithms to protect data integrity (96 -bit) n – Use symmetric key cryptography – HMAC-SHA-96, HMAC-MD 5 -96 14

AH Packet Details New IP header Next header Payload length Reserved Security Parameters Index (SPI) Authenticated Sequence Number Encapsulated TCP or IP packet Old IP header (only in Tunnel mode) TCP header Hash of everything else Data Authentication Data 15

Encapsulating Security Payload (ESP) Provides all that AH offers, and n in addition provides data confidentiality n – Uses symmetric key encryption 16

ESP Details n Same as AH: – Use 32 -bit sequence number to counter replaying attacks – Use integrity check algorithms n Only in ESP: – Data confidentiality: n Uses symmetric key encryption algorithms to encrypt packets 17

ESP Packet Details IP header Next header Payload length Reserved Security Parameters Index (SPI) Authenticated Sequence Number Initialization vector TCP header Data Pad length Next Encrypted TCP packet Authentication Data 18

Question? 1. 2. Why have both AH and ESP? Both AH and ESP use symmetric key based algorithms – – Why not public-key cryptography? How are the keys being exchanged? What algorithms should we use? Similar to deciding on the cipher-suite in SSL 19

Outline Why IPsec? n IPsec Architecture n Internet Key Exchange (IKE) n IPsec Policy n Discussion n 20

Internet Key Exchange (IKE) Exchange and negotiate security policies n Establish security sessions n – Identified as Security Associations Key exchange n Key management n Can be used outside IPsec as well n 21

IPsec/IKE Acronyms n Security Association (SA) – Collection of attribute associated with a connection – Is asymmetric! n n n One SA for inbound traffic, another SA for outbound traffic Similar to cipher-suites in SSL Security Association Database (SADB) – A database of SAs 22

IPsec/IKE Acronyms n Security Parameter Index (SPI) – A unique index for each entry in the SADB – Identifies the SA associated with a packet n Security Policy Database (SPD) – Store policies used to establish SAs 23

How They Fit Together SPD SA-1 SA-2 SADB SPI 24

SPD and SADB Example A’s SPD Transport Mode A C B D Tunnel Mode A’s SADB From To Protocol Port Policy A B Any AH[HMAC-MD 5] From To Protocol SPI SA Record A B AH 12 HMAC-MD 5 key From To Protocol Port Policy Tunnel Dest Asub Bsub Any ESP[3 DES] D To Protocol SPI SA Record ESP 14 3 DES key From Asub Bsub C’s SPD C’s SADB 25

How It Works n IKE operates in two phases – Phase 1: negotiate and establish an auxiliary end-to-end secure channel n n Used by subsequent phase 2 negotiations Only established once between two end points! – Phase 2: negotiate and establish custom secure channels n Occurs multiple times – Both phases use Diffie-Hellman key exchange to establish a shared key 26

IKE Phase 1 n Goal: to establish a secure channel between two end points – This channel provides basic security features: n Source authentication n Data integrity and data confidentiality n Protection against replay attacks 27

IKE Phase 1 n n n 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 28

Examples All packets sent to address mybank. com must be encrypted using 3 DES with HMAC-MD 5 integrity check n All packets sent to address www. forum. com must use integrity check with HMAC-SHA 1 (no encryption is required) n 29

Phase 1 Exchange n Can operate in two modes: – Main mode n Six messages in three round trips n More options – Quick mode n Four messages in two round trips n Less options 30

Phase 1 (Main Mode) Initiator Responder [Header, SA 1] 31

Phase 1 (Main Mode) Initiator Responder [Header, SA 1] [Header, SA 2] Establish vocabulary for further communication 32

Phase 1 (Main Mode) Initiator Responder [Header, SA 1] [Header, SA 2] [Header, KE, Ni, {Cert_Reg} ] 33

Phase 1 (Main Mode) Initiator Responder Header, SA 1 [Header, SA 1] [Header, KE, Ni { , Cert_Req} ] [Header, KE, Nr {, Cert_Req}] Establish secret key using Diffie-Hellman key exchange Use nonces to prevent replay attacks 34

Phase 1 (Main Mode) Initiator Responder [Header, SA 1] [Header, KE, Ni {, Cert_Req} ] [Header, KE, Nr {, Cert_Req}] [Header, IDi, {CERT} sig] 35

Phase 1 (Main Mode) Initiator Responder [Header, SA 1] [Header, KE, Ni {, Cert_req}] [Header, KE, Nr {, Cert_req}] [Header, IDi, {CERT} sig] [Header, IDr, {CERT} sig] Signed hash of IDi (without Cert_req , just send the hash) 36

Phase 1 (Aggressive Mode) Initiator Responder [Header, SA 1, KE, Ni, IDi] 37

Phase 1 (Aggressive Mode) Initiator Responder [Header, SA 1, KE, Ni, IDi] [Header, SA 2, KE, Nr, IDr, [Cert]sig] [Header, [Cert]sig] First two messages combined into one (combine Hello and DH key exchange) 38

IPSec (Phase 1) n Four different way to authenticate (either mode) – Digital signature – Two forms of authentication with public key encryption – Pre-shared key n NOTE: IKE does use public-key based cryptography for encryption 39

IPSec (Phase 2) n Goal: to establish custom secure channels between two end points – End points are identified by <IP, port>: n e. g. <www. mybank. com, 8000> n e. g. All packets going to 128. 124. 100. 0/24 – Or by packet: – Use the secure channel established in Phase 1 for communication 40

IPSec (Phase 2) Only one mode: Quick Mode n Multiple quick mode exchanges can be multiplexed n Generate SAs for two end points n Can use secure channel established in phase 1 n 41

IP Payload Compression Used for compression n Can be specified as part of the IPSec policy n Will not cover! n 42

Outline Why IPsec? n IPsec Architecture n Internet Key Exchange (IKE) n IPSec Policy n Discussion n 43

IPsec Policy n n Phase 1 policies are defined in terms of protection suites Each protection suite – Must contain the following: n n Encryption algorithm Hash algorithm Authentication method Diffie-Hellman Group – May optionally contain the following: n n Lifetime … 44

IPSec Policy n n Phase 2 policies are defined in terms of proposals Each proposal: – May contain one or more of the following n n AH sub-proposals ESP sub-proposals IPComp sub-proposals Along with necessary attributes such as – Key length, life time, etc 45

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

IPsec Policy Example n In English: – All traffic to 128. 104. 120. 0/24 must use one of the following: n n n AH with HMAC-SHA or, ESP with 3 DES as encryption algorithm and (HMAC-MD 5 or HMAC-SHA as hashing algorithm) In IPsec: – [AH: HMAC-SHA] or, – [ESP: (3 DES and HMAC-MD 5) or (3 DES and HMAC-SHA)] 47

Virtual Private Networks (VPNs) n Virtual – It is not a physically distinct network n Private – Tunnels are encrypted to provide confidentiality n CS dept might have a VPN – I can be on this VPN while traveling 48

Alice is Traveling Alice works for the mergers and acquisitions (M&A) department of takeover. com n She is at Smalltown taking over a meat-packing plant n She wants to access the M&A server at her company (confidentially of course) n 49

Alice is Traveling 50

Outline Why IPsec? n IPsec Architecture n Internet Key Exchange (IKE) n IPsec Policy n Discussion n 51

Discussion n IPSec is not the only solution! – Security features can be added on top of IP! n e. g. n Kerberos, SSL Confused? – IP, IPSec protocols are very complex! n Two modes, three sub protocols – Complexity is the biggest enemy of security 52

Discussion n Has it been used? – Yes—primarily used by some VPN vendors n But not all routers support it – No—it is not really an end-to-end solution n Authentication is too coarse (host based) n Default encryption algorithm too weak (DES) n Too complex for applications to use 53

Resources n IP, IPsec and related RFCs: – – – n http: //www. ietf. org/html. charters/ipsec-charter. html IPsec: RFC 2401, IKE: RFC 2409 www. freeswan. org Google search 54