1. Anish Arora CSE651 Introduction to Network Security
Lecture 7: IPSec
Anish Arora
CSE651
Introduction to Network Security

2. IP header data IP Review IP datagram is of the form
What IP header is (for v4):

3. IPv6 Header

4. TCP/IP Example

5. IP header data IP header TCP hdr HTTP hdr app data IP and TCP
Consider HTTP traffic (over TCP)
IP encapsulates TCP
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.

6. 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

7. 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

8. IP Security Uses Applications include: For secure routing purposes
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

9. IPSec Use Scenario
Stallings Fig 16-1.

10. 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

11. 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

12. SSL vs IPSec SSL (and IEEE standard TLS) IPSec
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)
Is complex (and has some flaws)

13. SSL vs IPSec (contd.) IPSec implementation SSL 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

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

15. 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

16. IPSec Architecture

17. 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

18. Transport & Tunnel Modes
Stallings Fig 16-5.

19. 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

20. 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

21. 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

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

23. AH vs ESP AH ESP 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

24. ESP’s 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 Caesar’s cipher
Can make use of keys of varying length
No IV is required
Null(P,K) = P for any P and any key K

25. 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

26. 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?

27. 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

28. Authentication Header
Stallings Fig 16-3.

29. 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

30. Encapsulating Security Payload
Stallings Fig 16-7.

31. IKE IKE has 2 phases Phase 1 is comparable to SSL session
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!

32. 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!

33. 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

34. IKE 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

35. IKE 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
Alice
Bob
Main difference from main mode
Not trying to protect identities
Cannot negotiate g or p

36. 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

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

38. 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)

39. 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!

40. 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…

41. 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!

42. Summary of Key Management
IKE=ISAKMP+Oakley
automated system for on-demand creation and distribution of keys for enabling SA’s 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)

43. Oakley 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

44. ISAKMP 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

46. ISAKMP
Stallings Fig

47. 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

48. Types 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)

49. 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

50. Cases of Combining Security Associations
Stallings Fig

51. Said another way… End to end security: H1* == H2*
VPN: H1—SG1* == SG2*—H2
End-to-end security +VPN: H1*—SG1* == SG2*—H2*
Remote access: H1*==SG2*—H2*

52. 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…

53. IPSec 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…