Title: Lecture 7: IPSec
1Lecture 7 IPSec
- Anish Arora
- CSE651
- Introduction to Network Security
-
2IP Review
- IP datagram is of the form
data
IP header
- What IP header is (for v4)
3IPv6 Header
4TCP/IP Example
5IP and TCP
- Consider HTTP traffic (over TCP)
- IP encapsulates TCP
- TCP encapsulates HTTP
- Routers can inspect inner headers
data
IP header
IP header
TCP hdr
HTTP hdr
app data
- IP data includes TCP header, etc.
6IP 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
7IPSec
- 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
8IP 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
9IPSec Use Scenario
10IP 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
11Benefits 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
12SSL 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)
13SSL 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
14IPSec Security
- What kind of protection?
- Confidentiality?
- Integrity?
- Both?
- What to protect?
- Data?
- Header?
- Both?
- ESP/AH do some combinations of these
15IPSec Architecture
- specification is quite complex
- defined in numerous RFCs
- including RFC 2401/2402/2406/2408
- many others, grouped by category
- mandatory in IPv6, optional in IPv4
16IPSec Architecture
17IP 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
18Transport Tunnel Modes
19Transport 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
20IPSec Transport Mode
IP header
data
data
IP header
ESP/AH
- 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
21IPSec 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
22Comparison of IPSec Modes
- Transport Mode
- Host-to-host
- Tunnel Mode
- Firewall-to-firewall
- Transport mode not necessary
- Transport mode is more efficient
IP header
data
data
IP header
ESP/AH
IP header
data
IP header
new IP hdr
ESP/AH
data
23AH 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
24ESPs NULL Encryption
- According to RFC 2410
- NULL encryption is a block cipher the origins of
which appear to be lost in antiquity - Despite rumors, there is no evidence that NSA
suppressed publication of this algorithm - Evidence suggests it was developed in Roman times
as exportable version of Caesars cipher - Can make use of keys of varying length
- No IV is required
- Null(P,K) P for any P and any key K
25Why 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
26Why 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?
27Protocol 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
28Authentication Header
29Encapsulating 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
30Encapsulating Security Payload
31IKE
- 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 2s do not occur, it is more
expensive to have two phases!
32IKE 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!
33IKE Phase 1
- Uses ephemeral Diffie-Hellman to establish
session key - Achieves perfect forward secrecy (PFS)
- Let a be Alices Diffie-Hellman exponent
- Let b be Bobs Diffie-Hellman exponent
- Let g be generator and p prime
- Recall p and g are public
34IKE Phase 1 Digital Signature (Main Mode)
IC, CP
IC,RC, CS
IC,RC, ga mod p, NA
IC,RC, gb mod p, NB
IC,RC, E(Alice, proofA, K)
Alice
Bob
IC,RC, E(Bob, proofB, 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)
- proofA h(SKEYID,ga,gb,IC,RC,CP,Alice)Alice
35IKE Phase 1 Public Key Signature (Aggressive
Mode)
IC, Alice, ga mod p, RA, CP
IC,RC, Bob, RB, gb mod p, CS, proofB
IC,RC, proofA
Bob
Alice
- Main difference from main mode
- Not trying to protect identities
- Cannot negotiate g or p
36Main 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 Alices and Bobs
identity in main mode
37Public Key Encryption Issue?
IC, CP, ga mod p, AliceBob, RABob
IC,RC, CS, gb mod p, BobAlice, RBAlice,
proofB
Trudy as Alice
Trudy as Bob
IC,RC, proofA
- Trudy can create exchange that appears to be
between Alice and Bob - Appears valid to any observer, including Alice
and Bob!
38Plausible 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)
39IKE 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!
40IKE 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
41IKE 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, its not!
42Summary of Key Management
- IKEISAKMPOakley
- automated system for on-demand creation and
distribution of keys for enabling SAs in large
systems in a protected manner - Typically SAs need 2 pairs of keys
- 2 per direction for AH ESP
- Perfect forward secrecy desired ? D-H
- (IPSec also mandates support for manual key
management)
43Oakley
- a key exchange protocol based on Diffie-Hellman
key exchange - adds features to address weaknesses
- cookies, groups (global parameters), nonces, DH
key exchange with authentication - Cookie generation criteria
- must depend on the specific parties
- must not be possible for anyone other than the
issuing entity to generate cookies that will be
accepted by that entity - cookie generation function must be fast to thwart
attacks intended to sabotage CPU resources - a hash over the IP source destination address,
the UDP source and destination ports and a
locally generated secret random value
44ISAKMP
- Internet Security Association and Key Management
Protocol - provides framework for key management
- defines procedures and packet formats to
establish, negotiate, modify, delete SAs - independent of key exchange protocol, encryption
alg, authentication method - Phase 1 ISAKMP peers establish bidirectional
secure channel using main mode or aggressive mode
- Phase 2 negotiation of security services for
IPsec (maybe for several SAs) using quick mode
can have multiple Phase 2 exchanges, e.g., to
change keys
45 ISAKMP Phase 1 exchange protocols
- all based on ephemeral Diffie-Hellman exchange
- Main mode 6 messages negotiate policy (2
msg.), D-H nonces (2), authenticate D-H (2) - Aggressive mode 3 messages negotiate policy,
exchange D-H public values, identities,
authenticate responder (2 msg), authenticate
initiator - typically uses UDP (port 500), may use other
protocols
46ISAKMP
47Security 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
48Types of Security Associations
- Either transport mode or tunnel mode
- Transport mode is between two hosts
- AH or ESP after IPv4 options, before UDP/TCP
- IPv6 after base header and extensions,
before/after destination options - Tunnel mode is wrt to one or two security
gateways - outer header points only to tunnel endpoint
- inner header points to source and destination
- security header is between outer and inner
- protects entire packet (in AH, but not
necessarily in ESP)
49Security 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 SAs
- 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
50Cases of Combining Security Associations
51Said another way
- End to end security H1 H2
- VPN H1SG1 SG2H2
- End-to-end security VPN H1SG1 SG2H2
- Remote access H1SG2H2
52Security Association Implementation
- Security Associations Database
- for inbound processing look at
- outer headers 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
53IPSec
- After IKE Phase 1, we have an IKE SA
- After IKE Phase 2, we have an IPSec SA
- Both sides have a shared symmetric key
- Now what?
- We want to protect IP datagrams
- But what is an IP datagram?
- From the perspective of IPSec