1. SMUCSE 5349/49 IP Sec

2. SMUCSE 5349/7349 Basics Network-level: all IP datagrams covered Mandatory for next-generation IP (v6), optional for current-generation (v4) Authentication-only or confidentiality too

3. SMUCSE 5349/7349 Architecture & Concepts Host or gateway implementation Tunnel vs. Transport mode Security association (SA) –Security parameter index (SPI) –Security policy database (SPD) –SA database (SAD) Encapsulating security payload (ESP) Authentication header (AH)

4. SMUCSE 5349/7349 IPSec Placement Host implementation –OS integrated, modify the IP code Bump-in-the-stack –Layer between data link and IP Bump-in-the-wire –IPSec outside host, in a router/firewall –Least intrusive

5. SMUCSE 5349/7349 AB Encrypted Tunnel Gateway New IP Header AH or ESP Header TCPDataOrig IP Header Encrypted Unencrypted Tunnel vs. Transport Mode

6. SMUCSE 5349/7349 Transport Mode Security ESP protects higher layer payload only AH can protect IP headers as well as higher layer payload IP header IP options IPSec header Higher layer protocol ESP AH Real IP destination

7. SMUCSE 5349/7349 Tunnel Mode Security ESP applies only to the tunneled packet AH can be applied to portions of the outer header Outer IP header Inner IP header IPSec header Higher layer protocol ESP AH Real IP destination Destination IPSec entity

8. SMUCSE 5349/7349 Security Association - SA One way relationship (uni-directional) Determine IPSec processing for senders Determine IPSec decoding for destination SAs are not fixed! Generated and customized per traffic flows (manual as well as dynamic) –If manual, no lifetime; dynamic has lifetime

9. SMUCSE 5349/7349 Security Parameters Index - SPI Can be up to 32 bits large The SPI allows the destination to select the correct SA under which the received packet will be processed (according to the agreement with the sender) –The SPI is sent with the packet by the sender SPI + Dest IP address + IPSec Protocol (AH or ESP) uniquely identifies a SA

10. SMUCSE 5349/7349 SA Database - SAD Holds parameters for each SA –Lifetime of this SA –AH and ESP information –Tunnel or transport mode Every host or gateway participating in IPSec has their own SA database

11. SMUCSE 5349/7349 SA Bundle More than 1 SA can apply to a packet Example: ESP does not authenticate new IP header. How to authenticate? –Use SA to apply ESP w/out authentication to original packet –Use 2 nd SA to apply AH

12. SMUCSE 5349/7349 Security Policy Database - SPD What traffic to protect? Has incoming traffic been properly secured? Policy entries define which SA or SA bundles to be used on IP traffic Each host or gateway has their own SPD Index into SPD by Selector fields –Dest IP, Source IP, Transport Protocol, IPSec Protocol, Source & Dest Ports, etc.

13. SMUCSE 5349/7349 SPD Entry Actions Discard –Do not let in or out Bypass –Outbound: do not apply IPSec –Inbound: do not expect IPSec Protect – will point to an SA or SA bundle –Outbound: apply security –Inbound: check that security has been applied

14. SMUCSE 5349/7349 SPD Protect Action If the SA does not exist –Outbound processing: use IKE to generate SA dynamically –Inbound processing: drop packet

15. SMUCSE 5349/7349 Is it for IPSec? If so, which policy entry to select? … SPD (Policy) … SA Database IP Packet Outbound packet (on A) AB SPI & IPSec Packet Send to B Determine the SA and its SPI IPSec processing Outbound Processing

16. SMUCSE 5349/7349 Use SPI to index the SAD … SA Database Original IP Packet SPI & Packet Inbound packet (on B) AB From A Inbound Processing … SPD (Policy) Was packet properly secured?

17. SMUCSE 5349/49 Authenticated Header (AH)

18. SMUCSE 5349/7349 AH Security Connectionless integrity –Flow/error control left to transport layer –Data integrity Authentication –Can “trust” IP address source –Use MAC to authenticate Anti-replay feature Integrity check value

19. SMUCSE 5349/7349 Integrity Check Value - ICV Message authentication code (MAC) calculated over – IP header field that do not change or are predictable –IPSec protocol header minus where the ICV value goes –Upper-level data Code may be truncated to first 96 bits

20. SMUCSE 5349/7349 AH Header Format SPI Sequence Number ICV Next Header (TCP/UDP) Payload Length Reserved

21. SMUCSE 5349/7349 AH Modes Tunnel Transport Nested headers –Multiple SAs applied to same message –Nested tunnels

22. SMUCSE 5349/7349 Processing Outbound Messages Insert Next Header and SPI field Compute the sequence no. field –If processing < 2 32 message Increment Place new value in AH and SAD –Else, Change keys at wrap around if replay protection is enabled Else set to 1

23. SMUCSE 5349/7349 Outbound Processing (cont’d) If transport mode, change preceding IP header’s Next Header field to AH If tunnel mode, add the tunnel header –Recompute header length, header checksum etc. Compute authentication value

24. SMUCSE 5349/7349 Outbound Processing (cont’d) ICV Calculated on entire IP packet including AH header –Zero out all mutable fields including authentication data field –Get the key from SA –HMAC-MD5-96 or HMAC-SHA-96 –Insert the cryptographic hash code in the AH header

25. SMUCSE 5349/7349 Outbound Processing (cont’d) Fragment the Message IPSec processing may result in large message which will be fragmented –Transport mode Source address initiator of the message Total message authentication before fragmentation –Tunnel mode Message may have been fragmented already Authenticate the fragment and further fragment

26. SMUCSE 5349/7349 Input Processing Identify the inbound SA –If not found, drop the packet Replay protection check –Drops duplicates within the window –Drops late arrivals outside window –Advances with the receipt of authenticated message

27. SMUCSE 5349/7349 Inbound Processing (cont’d) Verify authentication data –Authentication hash computed and checked –If no match, discard Strip off the AH header and continue IPSec processing for any remaining IPSec headers –Either an upper layer protocol header or a tunnel header is encountered

28. SMUCSE 5349/7349 Replay Protection Sequence number checking –Anti-replay is used only if authentication is selected –Sequence number should be the first check on a packet upon looking up an SA –Duplicates are rejected! 0 Sliding Window size >= 32 reject Check bitmap, verify if new verify

29. SMUCSE 5349/7349 Anti-replay Feature Sequence number counter - 32 bit for outgoing IPSec packets Anti-replay window –32-bit (or more) –Bit-map for detecting replayed packets –Window should not be advanced until the packet has been authenticated –Without authentication, malicious packets with large sequence numbers can advance window unnecessarily Valid packets may get dropped

30. SMUCSE 5349/49 Encapsulated Security Protocol (ESP)

31. SMUCSE 5349/7349 Encapsulated Security Protocol (ESP) –Confidentiality for upper layer protocol –Traffic flow confidentiality –Data origin authentication and connectionless integrity (optional)

32. SMUCSE 5349/7349 ESP Packet Tunnel Mode

33. SMUCSE 5349/7349 Outbound Packet Processing Form ESP payload Pad as necessary Encrypt result [payload, padding, pad length, next header] Apply authentication –Allow rapid detection of replayed/bogus packets –Allow potential parallel processing - decryption & verifying authentication code

34. SMUCSE 5349/7349 Outbound Packet Processing (cont’d) Sequence number generation ICV calculation –ICV includes whole ESP packet minus authentication data field –Implicit padding of ‘0’s between next header and authentication data is used to satisfy block size requirement for ICV algorithm

35. SMUCSE 5349/7349 SPI Sequence Number Original IP Header Integrity Check Value Authentication coverage Encrypted Payload (TCP Header and Data) Variable Length Pad Length Padding (0-255 bytes) Next Header ESP Transport Example

36. SMUCSE 5349/7349 Inbound Packet Processing Packet decryption –Decrypt [ESP payload,padding,pad length,next header] per SA specification –Processing (stripping) padding per encryption algorithm –Reconstruct the original IP datagram Authentication verification (optional)

37. SMUCSE 5349/49 Internet Key Exchange (IKE)

38. SMUCSE 5349/7349 Key Management AH and ESP require encryption and authentication keys Process to negotiate and establish IPSec SA’s between two entities

39. SMUCSE 5349/7349 Manual Key Management Mandatory Useful when IPSec developers are debugging Keys exchanged offline (phone, email, etc.) Set up SPI and negotiate parameters Not scalable

40. SMUCSE 5349/7349 IKE Use the frame work of ISAKMP Internet Security Assignment and Key Management Protocol Developed by NSA Implements parts of two key management protocols –Oakley and SKEME

41. SMUCSE 5349/7349 IKE - Phases Used when an outbound packet does not have an SA Tow phases: –Phase I: Establish an IKE SA (main mode, aggressive mode) Used to define encryption & authentication of IKE traffic Multiple IPSec SAs can be established with one IKE SA Bidirectional –Phase II: Use IKE SA to negotiate IPSec Sas (quick mode)

42. SMUCSE 5349/7349 Phase I – Create IKE SA Negotiate protection suite Use Diffie-Hellman to establish shared secret –3 groups of DH defined Authenticate the shared secret, IKE SA –Preshared keys (secret) –Digital signatures –Public-keys

43. SMUCSE 5349/7349 IKE Modes Phase I –Main Mode – flexible, 6 messages Checks cookies before DH work –Aggressive mode – faster, 3 messages Open to DoS, doesn’t check cookie before DH work Used mostly for remote access Phase II – Quick mode

44. SMUCSE 5349/7349 Oakley Key Exchange Designed to –Leverage advantages of DH Fresh keys Secret never on the transit –Counter DH weaknesses No information on the Ids of the parties Man-in-the-middle attack Computationally intensive

45. SMUCSE 5349/7349 Oakley - Major Features Cookies to thwart DoS Nonce to prevent replay DH for key exchange Authenticated key exchange Specification of global parameters for DH

46. SMUCSE 5349/7349 Cookies Requirements –Depend on specific parties –Only the issuing entity can generate acceptable cookies – implies issuer using local secret –Cookie generation and verification must be fast Suggested - Hash over IP Src/Dest; UDP Src/Dest; local secret

47. SMUCSE 5349/7349 SA, CKY-I IR InitiatorResponder SA, CKY-R Negotiate IKE SA parameters Nonce I, Y I Nonce R, Y R ID I, Hash I ID R, Hash R Exchange items to generate secret Send hash digest so peer can authenticate sender Example: Main Mode Preshared Generate SKEYID

48. SMUCSE 5349/7349 Main Mode Preshared PRF, Pseudo-Random Function SKEYID root secret =PRF(preshared-key,Ni|Nr) SKEYID_d for IPSec SA =PRF(SKEYID,K|CKY-I|CKY-R|0) K is the secret generated by DH SKEYID_a for IKE message data auth & integrity = PRF(SKEYID,SKEYID_d|K|CKY-I|CKY-R|1) SKEYID_e use to encrypt IKE messages = PRF(SKEYID,SKEYID_a|K|CKY-I|CKY-R|2)

49. SMUCSE 5349/7349 Main Mode Preshared Hashes To authenticate each other, each entity generates a hash digest that only the peer could know Hash-I= PRF(SKEYID,Y I |Y R |CKY-I|CKY-R|SA Offer|ID-I) Hash-R = PRF(SKEYID,Y R |Y I |CKY-R|CKY-I|SA Offer|ID-R)

50. SMUCSE 5349/7349 Phase II What traffic does SA cover ? Initiator specifies which entries (selectors) in SPD are for this IPSec SA, sends off to responder Keys and SA attributes communicated with the Phase I - IKE SA –Passes encrypted & authenticated

51. SMUCSE 5349/7349 HASH1, IPSec SA, Nonce I, [New K] IR InitiatorResponder HASH2, SA, Nonce R, [New K] Negotiate IPSec SA Parameters, [PFS] Example: Quick Mode HASH3 ‘Liveness’ proof for Responder

52. SMUCSE 5349/7349 IKE Summary