Lecture 7 IPSec Anish Arora CSE 651 Introduction

Lecture 7: IPSec Anish Arora CSE 651 Introduction to Network Security

IP Review • IP datagram is of the form IP header • What IP header is (for v 4): data

IPv 6 Header

TCP/IP Example

IP and TCP • • • Consider HTTP traffic (over TCP) IP encapsulates TCP encapsulates HTTP Routers can inspect inner headers IP header data IP header TCP hdr HTTP hdr app data IP data includes TCP header, etc.

IP Security • So far, we have considered some application specific security mechanisms § e. g. Kerberos, PGP, https § easy access to user credentials § can extend without waiting for OS vendor § but need to design again and again • and some transport-specific security § seamless, but difficult to get credentials • but there are security concerns that cut across protocol layers § security implemented by network for all applications § reduced key management, fewer application changes, VPNs

IPSec • services provide § access control § connectionless integrity § data origin authentication § rejection of replayed packets - a form of partial sequence integrity § confidentiality (encryption) § limited traffic flow confidentiality • applicable to use over LANs, across public & private WANs, & for the Internet

IP Security Uses • Applications include: § secure branch office connectivity over the Internet § secure remote access over the Internet § establishing extranet and intranet connectivity with partners § enhancing electronic commerce security • For secure routing purposes

IPSec Use Scenario

IP Security Overview IPSec is not a single security protocol Instead, IPSec provides a set of security algorithms plus a general framework that allows a pair of communicating entities to use whichever algorithms provide security appropriate for the communication § for both IPv 4 and IPv 6 unicast

Benefits of IPSec • in a firewall/router provides strong security to all traffic crossing the perimeter • is resistant to bypass • is below transport layer, hence transparent to applications • can be transparent to end users • can provide security for individual users if desired

SSL vs IPSec • SSL (and IEEE standard TLS) § Lives at socket layer (part of user space) § Has encryption, integrity, authentication, etc. § Is a relatively simple specification • IPSec § Lives at the network layer (part of the OS) § Has encryption, integrity, authentication, etc. § Is complex (and has some flaws)

SSL vs IPSec (contd. ) • IPSec implementation § Requires changes to OS, but no changes to applications • SSL implementation § Requires changes to applications, but no changes to OS • SSL built into Web application early on (Netscape) • IPSec used in VPN applications (secure tunnel) • Reluctance to retrofit applications for SSL • Reluctance to use IPSec due to complexity and interoperability issues

IPSec Security • What kind of protection? § Confidentiality? § Integrity? § Both? • What to protect? § Data? § Header? § Both? • ESP/AH do some combinations of these

IPSec Architecture • specification is quite complex • defined in numerous RFC’s § including RFC 2401/2402/2406/2408 § many others, grouped by category • mandatory in IPv 6, optional in IPv 4

IPSec Architecture

IP Security Architecture • Authentication header (AH) § access control, integrity, authentication, replay protection • Encapsulating security payload (ESP) § access control, confidentiality, traffic flow confidentiality • Key management protocols (IKE)= OAKLEY + ISAKMP § for any upper-layer protocol, no effect on rest of Internet, algorithm independent

Transport & Tunnel Modes

Transport vs Tunnel Mode ESP • transport mode is used to encrypt & optionally authenticate IP data § data protected but header left in clear § can do traffic analysis but is efficient § good for ESP host to host traffic • tunnel mode encrypts entire IP packet § add new header “outside” for next hop § good for VPNs, gateway to gateway security

IPSec Transport Mode IP header data IP header ESP/AH data • Transport mode designed for host-to-host • Transport mode is efficient § Adds minimal amount of extra header • The original header remains § Passive attacker can see who is talking

IPSec Tunnel Mode IP header data new IP hdr ESP/AH IP header data • Tunnel mode for firewall to firewall traffic • Original IP packet encapsulated in IPSec • Original IP header not visible to attacker § New header from firewall to firewall § Attacker does not know which hosts are talking

Comparison of IPSec Modes • Transport Mode • § Host-to-host IP header data • IP header ESP/AH • IP header data ESP/AH IP header data Tunnel Mode § Firewall-to-firewall data • Transport mode not necessary • Transport mode is more efficient Tunnel Mode new IP hdr Transport Mode

AH vs ESP • AH § Authentication Header § Integrity only (no confidentiality) § Integrity protect everything beyond IP header and some fields of header (why not all fields? ) • ESP § § Encapsulating Security Payload Integrity and confidentiality Protects everything beyond IP header Integrity only by using NULL encryption

Why Does AH Exist? (1) • Cannot encrypt IP header § Routers must look at the IP header § IP addresses, TTL, etc. § IP header exists to route packets! • AH protects immutable fields in IP header § Cannot integrity protect all header fields § TTL, for example, must change • ESP does not protect IP header at all

Why Does AH Exist? (2) • ESP encrypts everything beyond IP header (if non-null encryption) • If ESP encrypted, firewall cannot look at TCP header (e. g. , port #) • Why not use ESP with null encryption? § firewall sees ESP header but doesn't know whether null encryption used § end systems know but not firewalls • Aside 1: Do firewalls reduce security? • Aside 2: Is IPSec compatible with NAT?

Protocol: Authentication Header (AH) • provides support for data integrity & authentication of IP packets § includes packet header (unlike ESP) § end system/router can authenticate user/application § prevents address spoofing attacks by tracking sequence numbers § uses sliding window § if sequence number cycles, new SA is formed • based on use of a MAC § HMAC-MD 5 -96 or HMAC-SHA-1 -96 • parties must share a secret key

Authentication Header

Encapsulating Security Payload (ESP) • provides message content confidentiality & limited traffic flow confidentiality • can optionally provide the same authentication services as AH § order is to encrypt first, and then authenticate • supports range of ciphers, modes, padding § including DES-CBC (common), Triple-DES, RC 5, IDEA, CAST § including HMAC with MD 5 or SHA-1 § pad to meet block size, for traffic flow

Encapsulating Security Payload

IKE • IKE has 2 phases § Phase 1 IKE security association (SA) § Phase 2 AH/ESP security association • Phase 1 is comparable to SSL session • Phase 2 is comparable to SSL connection • No obvious need for two phases in IKE • If multiple Phase 2’s do not occur, it is more expensive to have two phases!

IKE Phase 1 • Four different “key” options § Public key encryption (original version) § Public key encryption (improved version) § Public key signature § Symmetric key • For each of these, two different “modes” § Main mode § Aggressive mode • 8 versions of IKE Phase 1!

IKE Phase 1 • Uses ephemeral Diffie-Hellman to establish session key § Achieves perfect forward secrecy (PFS) • Let a be Alice’s Diffie-Hellman exponent • Let b be Bob’s Diffie-Hellman exponent • Let g be generator and p prime • Recall p and g are public

IKE Phase 1: Digital Signature (Main Mode) IC, CP IC, RC, CS IC, RC, ga mod p, NA Alice IC, RC, gb mod p, NB IC, RC, E(“Alice”, proof. A, K) IC, RC, E(“Bob”, proof. B, K) • CP = crypto proposed, CS = crypto selected • IC = initiator “cookie”, RC = responder “cookie” • K = h(IC, RC, gab mod p, NA, NB) • SKEYID = h(NA, NB, gab mod p) • proof. A = [h(SKEYID, ga, gb, IC, RC, CP, “Alice”)]Alice Bob

IKE Phase 1: Public Key Signature (Aggressive Mode) IC, “Alice”, ga mod p, RA, CP IC, RC, “Bob”, RB, gb mod p, CS, proof. B Alice • IC, RC, proof. A Main difference from main mode § Not trying to protect identities § Cannot negotiate g or p Bob

Main vs Aggressive Modes • Main mode MUST be implemented • Aggressive mode SHOULD be implemented § In other words, if aggressive mode is not implemented, “you should feel guilty about it” • Might create interoperability issues • For public key signature authentication § Passive attacker knows identities of Alice and Bob in aggressive mode § Active attacker can determine Alice’s and Bob’s identity in main mode

Public Key Encryption Issue? IC, CP, ga mod p, {“Alice”}Bob, {RA}Bob IC, RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proof. B Trudy as Alice IC, RC, proof. A Trudy as Bob • Trudy can create exchange that appears to be between Alice and Bob • Appears valid to any observer, including Alice and Bob!

Plausible Deniability • Trudy can create “conversation” that appears to be between Alice and Bob • Appears valid, even to Alice and Bob! • A security failure? • In this mode of IPSec, it is a feature § Plausible deniability: Alice and Bob can deny that any conversation took place! • In some cases it might be a security failure § If Alice makes a purchase from Bob, she could later repudiate it (unless she had signed)

IKE Phase 1 Cookies • Cookies (or “anti-clogging tokens”) supposed to make denial of service more difficult • No relation to Web cookies • To reduce Do. S, Bob wants to remain stateless as long as possible • But Bob must remember CP from message 1 (required for proof of identity in message 6) • Bob must keep state from 1 st message on! • These cookies offer little Do. S protection!

IKE Phase 1 Summary • Result of IKE phase 1 is § Mutual authentication § Shared symmetric key § IKE Security Association (SA) • But phase 1 is expensive (in public key and/or main mode cases) • Developers of IKE thought it would be used for lots of things not just IPSec • Partly explains over-engineering…

IKE Phase 2 • Phase 1 establishes IKE SA • Phase 2 establishes IPSec SA • Comparison to SSL § SSL session is comparable to IKE Phase 1 § SSL connections are like IKE Phase 2 • IKE could be used for lots of things • But in practice, it’s not!

ISAKMP

Security Associations • a one-way (simplex) relationship between sender & receiver that affords security for traffic flow § can implement either AH or ESP • defined by 3 parameters: § Security Parameters Index (SPI) § IP Destination Address § Security Protocol Identifier

Security Associations • have a number of other parameters § sequence no, AH & EH info, lifetime, etc. • security associations can be combined/nested § achieved via transport adjacency or iterated tunneling § to implement both parties need to combine SA’s § form a security bundle • Transport adjacency: § End-to-end: AH and ESP two SAs (“SA bundle”) • Iterated tunneling: § Both endpoints the same, or only one, or neither

Cases of Combining Security Associations

Security Association Implementation Security Associations Database • for inbound processing: look at § outer header’s destination address § IPSec protocol (AH or ESP) § SPI (32 bit value) Security Policy Database • discard packet, or bypass or apply IPSec to both inbound & outbound • ordered list of filters (stateless firewall) • example: use ESP in transport mode using 3 DES-CBC, nested inside of AH in tunnel mode using HMAC-SHA • selectors: § § Destination IP address Source IP address Name Transport layer protocol…