IP Sec SMU CSE 534949 Basics Networklevel all

IP Sec SMU CSE 5349/49

Basics • Network-level: all IP datagrams covered • Mandatory for next-generation IP (v 6), optional for current-generation (v 4) • Authentication-only or confidentiality too SMU CSE 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) SMU CSE 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 SMU CSE 5349/7349

Tunnel vs. Transport Mode Encrypted Tunnel Gateway A ed t p y cr Unen Encrypted crypt U nen New IP Header SMU Gateway AH or ESP Header Orig IP Header CSE 5349/7349 TCP Data ed B

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

Tunnel Mode Security Outer IP IPSec Inner IP Higher header layer protocol Destination IPSec entity ESP Real IP destination AH • ESP applies only to the tunneled packet • AH can be applied to portions of the outer header SMU CSE 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 SMU CSE 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 SMU CSE 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 SMU CSE 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 SMU CSE 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. SMU CSE 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 SMU CSE 5349/7349

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

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

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

Authenticated Header (AH) SMU CSE 5349/49

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 SMU CSE 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 SMU CSE 5349/7349

AH Header Format Next Header Payload Length (TCP/UDP) Reserved SPI Sequence Number ICV SMU CSE 5349/7349

AH Modes • Tunnel • Transport • Nested headers – Multiple SAs applied to same message – Nested tunnels SMU CSE 5349/7349

Processing Outbound Messages • Insert Next Header and SPI field • Compute the sequence no. field – If processing < 232 message • Increment • Place new value in AH and SAD – Else, • Change keys at wrap around if replay protection is enabled • Else set to 1 SMU CSE 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 SMU CSE 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-MD 5 -96 or HMAC-SHA-96 – Insert the cryptographic hash code in the AH header SMU CSE 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 SMU CSE 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 SMU CSE 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 SMU CSE 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! reject 0 SMU Check bitmap, verify if new Sliding Window size >= 32 CSE 5349/7349 verify

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 SMU CSE 5349/7349

Encapsulated Security Protocol (ESP) SMU CSE 5349/49

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

ESP Packet Tunnel Mode SMU CSE 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 SMU CSE 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 SMU CSE 5349/7349

SPI Sequence Number Encrypted Authentication coverage ESP Transport Example SMU Original IP Header Payload (TCP Header and Data) Variable Length Padding (0 -255 bytes) Pad Length Next Header Integrity Check Value CSE 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) SMU CSE 5349/7349

Internet Key Exchange (IKE) SMU CSE 5349/49

Key Management • AH and ESP require encryption and authentication keys • Process to negotiate and establish IPSec SA’s between two entities SMU CSE 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 SMU CSE 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 SMU CSE 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) SMU CSE 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 SMU CSE 5349/7349

IKE Modes • Phase I – Main Mode – flexible, 6 messages • Checks cookies before DH work – Aggressive mode – faster, 3 messages • Open to Do. S, doesn’t check cookie before DH work • Used mostly for remote access • Phase II – Quick mode SMU CSE 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 SMU CSE 5349/7349

Oakley - Major Features • • • Cookies to thwart Do. S Nonce to prevent replay DH for key exchange Authenticated key exchange Specification of global parameters for DH SMU CSE 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 SMU CSE 5349/7349

Initiator I Responder SA, CKY-I Negotiate IKE SA parameters R SA, CKY-R Nonce. I, YI Nonce. R, YR Exchange items to generate secret Generate SKEYID IDI, Hash. I Send hash digest so peer can authenticate sender IDR, Hash. R Example: Main Mode Preshared SMU CSE 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 SMU CSE 5349/7349

Example: Quick Mode Initiator I Responder HASH 1, IPSec SA, Nonce. I, [New K] Negotiate IPSec SA Parameters, [PFS] R HASH 2, SA, Nonce. R, [New K] HASH 3 SMU ‘Liveness’ proof for Responder CSE 5349/7349

IKE Summary SMU CSE 5349/7349