Lecture 7: IPSec

Anish Arora

CSE651

Introduction to Network Security

IP Review

• What IP header is (for v4):

IP header data

• IP datagram is of the form

IPv6 Header

TCP/IP Example

IP and TCP

• Consider HTTP traffic (over TCP)• IP encapsulates TCP• TCP encapsulates HTTP• Routers can inspect inner headers

IP header TCP hdr HTTP hdr app data

IP header 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 IPv4 and IPv6 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 IPv6, optional in IPv4

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

• Tunnel Mode

IP header data

IP header ESP/AH data

IP header data

new IP hdr ESP/AH IP header data

• Transport Mode Host-to-host

• Tunnel Mode Firewall-to-firewall

• Transport mode not necessary

• Transport mode is more efficient

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-MD5-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, RC5, IDEA, CAST including HMAC with MD5 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)

• 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)

• proofA = [h(SKEYID,ga,gb,IC,RC,CP,“Alice”)]Alice

Alice Bob

IC, CP

IC,RC, CS

IC,RC, ga mod p, NA

IC,RC, E(“Alice”, proofA, K)

IC,RC, gb mod p, NB

IC,RC, E(“Bob”, proofB, K)

IKE Phase 1: Public Key Signature (Aggressive Mode)

• Main difference from main mode Not trying to protect identities

Cannot negotiate g or p

Alice Bob

IC, “Alice”, ga mod p, RA, CP

IC,RC, “Bob”, RB,

gb mod p, CS, proofB

IC,RC, proofA

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?

Trudyas Alice

Trudyas Bob

• Trudy can create exchange that appears to be between Alice and Bob

• Appears valid to any observer, including Alice and Bob!

IC,RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proofB

IC,RC, proofA

IC, CP, ga mod p,{“Alice”}Bob, {RA}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 DoS, 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 1st message on!

• These cookies offer little DoS 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 3DES-CBC, nested inside of

AH in tunnel mode using HMAC-SHA• selectors:

Destination IP address Source IP address Name Transport layer protocol…