Internet security csce 813 ipsec
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Internet Security CSCE 813 IPsec PowerPoint PPT Presentation


  • 64 Views
  • Uploaded on
  • Presentation posted in: General

Internet Security CSCE 813 IPsec. Reading. Oppliger: Chapter 14. Benefits of IPSec. When implemented in a firewall or router, IPSec provides strong security to ALL TRAFFIC crossing the perimeter. Traffic within the perimeter does not incur security overhead.

Download Presentation

Internet Security CSCE 813 IPsec

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Internet Security CSCE 813IPsec


Reading

  • Oppliger: Chapter 14

CSCE 813 - Farkas


Benefits of IPSec

  • When implemented in a firewall or router, IPSec provides strong security to ALL TRAFFIC crossing the perimeter. Traffic within the perimeter does not incur security overhead.

  • Cannot be bypassed (if all traffic must go through the firewall implementing IPSec)

  • Transparent to applications

  • Transparent to end users

CSCE 813 - Farkas


IPsec module 1

IPsec module 2

SPD

SPD

IKE

IKE

SA

IPsec

IPsec

SAD

SAD

IP Security Architecture

RFC 2401: Overview of Security Architecture

RFC 2402: Desc. Of packet authentication extension to IPv4 and IPv6

RFC 2406: Desc. Of packet encryption extension to IPv4 and IPv6

RFC 2408: Specification of key management capabilities

CSCE 813 - Farkas


Architecture

ESP

AH

Enryption algs.

Authentication algs.

DOI

Key Management

IPSec Document OverviewRFC 2401

CSCE 813 - Farkas


IPSec Services

CSCE 813 - Farkas


Security Association

  • One-way relationship

  • Identified by:

    • Security parameters index (SPI)

    • IP destination address

    • Security protocol identifier

  • Security Association Database:

    • SA parameters: sequence number counter, sequence number overflow, anti-replay window, AH information, ESP information, lifetime of SA, IPSec protocol mode, path MTU

  • Security Policy Database:

    • SA selectors: destination IP address, source IP address, UserID, Data Sensitivity Level, transport layer protocol, source and destination port

CSCE 813 - Farkas


Modes

CSCE 813 - Farkas


Encapsulating Security Payload(ESP)


ESP

  • Confidentiality: Encryptor

  • Integrity: Authenticator

  • Algorithm is determined by the Security Association (SA)

  • Each ESP has at most:

    • One cipher and one authenticator or

    • One cipher and zero authenticator or

    • Zero cipher and one authenticator or

    • Disallowed: zero cipher and zero authenticator or

CSCE 813 - Farkas


ESP Processing

  • Depends on mode in which ESP is employed

  • Both modes:

    • Cipher is authenticated

    • Authenticated plain text is not encrypted

  • Outbound: encryption happens first

  • Inbound: authentication happens first

CSCE 813 - Farkas


Protected Data

  • Depends on the mode of ESP

    • Transport mode: Upper-layer protocol packet

    • Tunnel mode: entire IP packet is protected

CSCE 813 - Farkas


Scope of ESP Encryption and Authentication

Transport mode

Authenticate

Encrypt

IPv4

Tunnel mode

Authenticate

Encrypt

CSCE 813 - Farkas


Outbound Processing

  • ESP headerinserted into the outgoing IP packet

    • Protocol field of IP header copied into Next header field of ESP

    • Remaining fields of ESP filled (SPI, sequence number, pad, pad length)

    • Protocol number of IP header is given the value ESP (50)

  • Encrypt packet from the beginning of payload data to the next header field

  • Authenticate packet form the ESP header, through the encrypted ciphertext to the ESP trailer and insert authentication data into ESP trailer

  • Packet is routed to the destination

CSCE 813 - Farkas


Inbound Processing

  • Check for SA of the packet

    • If no SA  drop packet

    • Otherwise: use valid SA to process the packet

  • Check sequence number

    • Invalid number  drop packet

  • Authenticate cipher text

    • Entire packet (without the authentication data) is processed by the authenticator

    • Match generated data with authentication data

    • No match  drop packet

CSCE 813 - Farkas


Inbound Processing

  • Decrypt ESP packet (from beginning on payload to the next header field)

    • Check pad integrity

  • Validate ESP mode using Next header field and decrypted payload

CSCE 813 - Farkas


Authentication Header


Authentication Header (AH)

  • Does NOT provide confidentiality

  • Provides:

    • Data origin authentication

    • Connectionless data integrity

    • Prevents spoofing attack

  • May provide:

    • Non-repudiation (depends on cryptographic alg.)

    • Anti-replay protection

  • Precision of authentication: granularity of SA

  • Protocol number: 51

CSCE 813 - Farkas


Authentication Data

  • AH protects outer IP header (unlike ESP)

  • Computed by using

    • Authentication algorithm (MD5, SHA-1)

    • Cryptographic key (secret key)

  • Sender: computes authentication data

  • Recipient: verifies data

CSCE 813 - Farkas


Scope of Authentication

Transport Mode

Authenticates except for mutable fields

IPv4

Tunnel Mode

Authenticates except for mutable fields in NEW IP hdr

IPv4

CSCE 813 - Farkas


Integrity Check Values

  • Message Authentication Code is Calculated from:

    • IP header fields that either do not change in transit or are predictable upon arrival – Fields that change and cannot be predicted are set to zero for the MAC calculation

    • AH header -- other than the authentication data field

    • Entire upper level protocol data

  • Note: both source and destination address fields are protected

CSCE 813 - Farkas


Combining Security Associations

CSCE 813 - Farkas


SA Bundle

  • Individual SA: either AH or ESP but NOT BOTH

  • Some traffic flow needs both – HOW?

  • Some traffic between host and security gateway requires different services than flow between security gateways

  • Security Association Bundle:

    • sequence of SAs through which traffic must be processed to provide a desired set of IPSec services

    • SAs within a bundle may terminate at different end points

CSCE 813 - Farkas


SA Combinations

  • Transport adjacency:

    • Applying more than one security protocol to the same IP packet without invoking tunneling.

    • Allows 1 level of combination (all IPSec processing are performed at one IPSec instance)

  • Iterated tunneling:

    • Multiple layers of security protocols efected through IP tunneling

    • Multiple levels of nesting (each tunnel may originate and terminate at different IPSec site)

  • Combination of the two approaches above.

CSCE 813 - Farkas


Transport Adjacency

Two bundled transport Sas

Inner SA: ESP transport SA without authentication (encrypted IP payload)

Outer SA: AH transport SA (covers ESP and the original IP header)

CSCE 813 - Farkas


Transport-Tunnel Bundle

Authenticate before encrypting

Inner SA: AH transport SA (authenticates the entire IP payload + IP header)

Outer SA: ESP tunnel SA (entire authenticated packet is encrypted + new IP header)

Advantages:

Authentication data is protected by encryption

Can store authentication information with the message (convenience)

CSCE 813 - Farkas


one or more SAs

local

intranet

Internet

local

intranet

  • Possible combinations:

  • AH in transport

  • ESP in transport

  • ESP followed by AH in transport

  • Any 1,2,3 inside an AH or ESP

  • tunnel

Combining Security Associations

  • Case 1: between end-systems

Figure from L. Buttyan

CSCE 813 - Farkas


single tunnel SA

local

intranet

Internet

local

intranet

  • Security provided:

  • Only between gateways

  • No host security

  • Only single tunnel SA

  • AH, ESP or ESP with

  • authentication

Combining Security Associations

  • Case 2: between gateways only

Figure from L. Buttyan

CSCE 813 - Farkas


single tunnel SA

One or two SAs

local

intranet

Internet

local

intranet

  • End-to-end protection:

  • Combinations for case 1 &2 allowed

  • Gateway tunnel: authentication and

  • confidentiality

  • 3.Hosts: application specific IPSec

Combining Security Associations

Case 3: host-to-gateway (Case 2 + end-to-end security)

Figure from L. Buttyan

CSCE 813 - Farkas


Tunnel SA

Internet

local

intranet

  • Remote host:

  • Host: tunnel mode to firewall

Combining Security Associations

  • Case 4: remote host

One or two SAs

Figure from L. Buttyan

CSCE 813 - Farkas


Next Class: Key ManagementISAKMPExchanges

CSCE 813 - Farkas


  • Login