Lecture 7: IPSec - PowerPoint PPT Presentation

About This Presentation
Title:

Lecture 7: IPSec

Description:

Lecture 7: IPSec Anish Arora CSE651 Introduction to Network Security – PowerPoint PPT presentation

Number of Views:155
Avg rating:3.0/5.0
Slides: 46
Provided by: TheL155
Category:
Tags: base | ipsec | lecture

less

Transcript and Presenter's Notes

Title: Lecture 7: IPSec


1
Lecture 7 IPSec
  • Anish Arora
  • CSE651
  • Introduction to Network Security

2
IP Review
  • IP datagram is of the form

data
IP header
  • What IP header is (for v4)

3
IPv6 Header
4
TCP/IP Example
5
IP 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.

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

13
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

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

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

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

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
  • Host-to-host
  • Tunnel Mode
  • Firewall-to-firewall
  • Transport mode not necessary
  • Transport mode is more efficient
  • Transport Mode

IP header
data
data
IP header
ESP/AH
  • Tunnel Mode

IP header
data
IP header
new IP hdr
ESP/AH
data
23
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

24
ESPs 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

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
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
31
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 2s 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 Alices Diffie-Hellman exponent
  • Let b be Bobs 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
Bob
Alice
  • 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 Alices and Bobs
    identity in main mode

37
Public 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!

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, its not!

42
Summary 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)

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

50
Cases of Combining Security Associations
51
Said another way
  • End to end security H1 H2
  • VPN H1SG1 SG2H2
  • End-to-end security VPN H1SG1 SG2H2
  • Remote access H1SG2H2

52
Security 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

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
Write a Comment
User Comments (0)
About PowerShow.com