smucse 5349/49 ip sec. smucse 5349/7349 basics network-level: all ip datagrams covered mandatory for...

SMU CSE 5349/49

IP Sec

SMU CSE 5349/7349

Basics

• Network-level: all IP datagrams covered• Mandatory for next-generation IP (v6),

optional for current-generation (v4)• Authentication-only or confidentiality

too

SMU CSE 5349/7349

Architecture & Concepts

• Host or gateway implementation• Tunnel vs. Transport mode• Security association (SA)

– Security parameter index (SPI)– Security policy database (SPD)– SA database (SAD)

• Encapsulating security payload (ESP)• Authentication header (AH)

SMU CSE 5349/7349

IPSec Placement

• Host implementation– OS integrated, modify the IP code

• Bump-in-the-stack– Layer between data link and IP

• Bump-in-the-wire– IPSec outside host, in a router/firewall– Least intrusive

SMU CSE 5349/7349

A B

Encrypted Tunnel

Gateway Gateway

New IP Header

AH or ESP Header

TCP DataOrig IP Header

Encrypted

Unencrypted Unencrypted

Tunnel vs. Transport Mode

SMU CSE 5349/7349

Transport Mode Security

• ESP protects higher layer payload only• AH can protect IP headers as well as

higher layer payload

IPheader

IPoptions

IPSecheader

Higherlayer protocol

ESP

AH

Real IPdestination

SMU CSE 5349/7349

Tunnel Mode Security

• ESP applies only to the tunneled packet• AH can be applied to portions of the

outer header

Outer IPheader

Inner IPheader

IPSecheader

Higherlayer protocol

ESP

AH

Real IP destinationDestinationIPSecentity

SMU CSE 5349/7349

Security Association - SA

• One way relationship (uni-directional)• Determine IPSec processing for senders• Determine IPSec decoding for

destination• SAs are not fixed! Generated and

customized per traffic flows (manual as well as dynamic)– If manual, no lifetime; dynamic has lifetime

SMU CSE 5349/7349

Security Parameters Index - SPI

• Can be up to 32 bits large• The SPI allows the destination to select

the correct SA under which the received packet will be processed (according to the agreement with the sender)– The SPI is sent with the packet by the

sender

• SPI + Dest IP address + IPSec Protocol (AH or ESP) uniquely identifies a SA

SMU CSE 5349/7349

SA Database - SAD

• Holds parameters for each SA– Lifetime of this SA– AH and ESP information– Tunnel or transport mode

• Every host or gateway participating in IPSec has their own SA database

SMU CSE 5349/7349

SA Bundle

• More than 1 SA can apply to a packet• Example: ESP does not authenticate

new IP header. How to authenticate?– Use SA to apply ESP w/out authentication to

original packet– Use 2nd SA to apply AH

SMU CSE 5349/7349

Security Policy Database - SPD

• What traffic to protect?• Has incoming traffic been properly

secured?• Policy entries define which SA or SA

bundles to be used on IP traffic• Each host or gateway has their own SPD• Index into SPD by Selector fields

– Dest IP, Source IP, Transport Protocol, IPSec Protocol, Source & Dest Ports, etc.

SMU CSE 5349/7349

SPD Entry Actions

• Discard– Do not let in or out

• Bypass– Outbound: do not apply IPSec– Inbound: do not expect IPSec

• Protect – will point to an SA or SA bundle– Outbound: apply security– Inbound: check that security has been applied

SMU CSE 5349/7349

SPD Protect Action

• If the SA does not exist– Outbound processing: use IKE to generate

SA dynamically– Inbound processing: drop packet

SMU CSE 5349/7349

Is it for IPSec?If so, which policyentry to select?

…

SPD(Policy)

…

SA Database

IP Packet

Outbound packet (on A)

A B

SPI & IPSec Packet

Send to B

Determine the SA and its SPI

IPSec processing

Outbound Processing

SMU CSE 5349/7349

Use SPI to index the SAD

…

SA Database

Original IP Packet

SPI & Packet

Inbound packet (on B) A B

From A

Inbound Processing

…

SPD(Policy)

Was packet properly secured?

SMU CSE 5349/49

Authenticated Header (AH)

SMU CSE 5349/7349

AH Security

• Connectionless integrity– Flow/error control left to transport layer – Data integrity

• Authentication– Can “trust” IP address source– Use MAC to authenticate

• Anti-replay feature• Integrity check value

SMU CSE 5349/7349

Integrity Check Value - ICV

• Message authentication code (MAC) calculated over– IP header field that do not change or are

predictable– IPSec protocol header minus where the ICV

value goes– Upper-level data

• Code may be truncated to first 96 bits

SMU CSE 5349/7349

AH Header Format

SPI

Sequence Number

ICV

Next Header (TCP/UDP)

Payload LengthReserved

SMU CSE 5349/7349

AH Modes

• Tunnel• Transport• Nested headers

– Multiple SAs applied to same message– Nested tunnels

SMU CSE 5349/7349

Processing Outbound Messages

• Insert Next Header and SPI field• Compute the sequence no. field

– If processing < 232 message• Increment• Place new value in AH and SAD

– Else, • Change keys at wrap around if replay protection

is enabled• Else set to 1

SMU CSE 5349/7349

Outbound Processing (cont’d)

• If transport mode, change preceding IP header’s Next Header field to AH

• If tunnel mode, add the tunnel header– Recompute header length, header

checksum etc.

• Compute authentication value

SMU CSE 5349/7349

Outbound Processing (cont’d)ICV

• Calculated on entire IP packet including AH header– Zero out all mutable fields including

authentication data field– Get the key from SA– HMAC-MD5-96 or HMAC-SHA-96– Insert the cryptographic hash code in the

AH header

SMU CSE 5349/7349

Outbound Processing (cont’d)Fragment the Message

• IPSec processing may result in large message which will be fragmented– Transport mode

• Source address initiator of the message• Total message authentication before

fragmentation

– Tunnel mode• Message may have been fragmented already• Authenticate the fragment and further fragment

SMU CSE 5349/7349

Input Processing

• Identify the inbound SA– If not found, drop the packet

• Replay protection check– Drops duplicates within the window– Drops late arrivals outside window– Advances with the receipt of authenticated

message

SMU CSE 5349/7349

Inbound Processing (cont’d)

• Verify authentication data– Authentication hash computed and checked– If no match, discard

• Strip off the AH header and continue IPSec processing for any remaining IPSec headers– Either an upper layer protocol header or a

tunnel header is encountered

SMU CSE 5349/7349

Replay Protection

• Sequence number checking– Anti-replay is used only if authentication is

selected– Sequence number should be the first check

on a packet upon looking up an SA– Duplicates are rejected!

0Sliding Windowsize >= 32

rejectCheck bitmap, verify if new

verify

SMU CSE 5349/7349

Anti-replay Feature

• Sequence number counter - 32 bit for outgoing IPSec packets

• Anti-replay window – 32-bit (or more)– Bit-map for detecting replayed packets– Window should not be advanced until the

packet has been authenticated– Without authentication, malicious packets

with large sequence numbers can advance window unnecessarily

• Valid packets may get dropped

SMU CSE 5349/49

Encapsulated Security Protocol (ESP)

SMU CSE 5349/7349

Encapsulated Security Protocol (ESP)

– Confidentiality for upper layer protocol– Traffic flow confidentiality– Data origin authentication and

connectionless integrity (optional)

SMU CSE 5349/7349

ESP Packet

Tunnel Mode

SMU CSE 5349/7349

Outbound Packet Processing

• Form ESP payload• Pad as necessary• Encrypt result [payload, padding, pad

length, next header]• Apply authentication

– Allow rapid detection of replayed/bogus packets

– Allow potential parallel processing - decryption & verifying authentication code

SMU CSE 5349/7349

Outbound Packet Processing (cont’d)

• Sequence number generation• ICV calculation

– ICV includes whole ESP packet minus authentication data field

– Implicit padding of ‘0’s between next header and authentication data is used to satisfy block size requirement for ICV algorithm

SMU CSE 5349/7349

SPI

Sequence Number

Original IP Header

Integrity Check Value

Au

then

tica

tio

n c

ove

rag

e

En

cryp

ted Payload (TCP Header and Data)

Variable Length

Pad Length

Padding (0-255 bytes)

Next Header

ESP T

ransp

ort

Exam

ple

SMU CSE 5349/7349

Inbound Packet Processing

• Packet decryption– Decrypt [ESP payload,padding,pad

length,next header] per SA specification– Processing (stripping) padding per

encryption algorithm– Reconstruct the original IP datagram

• Authentication verification (optional)

SMU CSE 5349/49

Internet Key Exchange (IKE)

SMU CSE 5349/7349

Key Management

• AH and ESP require encryption and authentication keys

• Process to negotiate and establish IPSec SA’s between two entities

SMU CSE 5349/7349

Manual Key Management

• Mandatory• Useful when IPSec developers are

debugging• Keys exchanged offline (phone, email,

etc.)• Set up SPI and negotiate parameters • Not scalable

SMU CSE 5349/7349

IKE

• Use the frame work of ISAKMP• Internet Security Assignment and Key

Management Protocol• Developed by NSA

• Implements parts of two key management protocols– Oakley and SKEME

SMU CSE 5349/7349

IKE - Phases

• Used when an outbound packet does not have an SA

• Tow phases:– Phase I: Establish an IKE SA (main mode,

aggressive mode)• Used to define encryption & authentication of

IKE traffic• Multiple IPSec SAs can be established with one

IKE SA• Bidirectional

– Phase II: Use IKE SA to negotiate IPSec Sas (quick mode)

SMU CSE 5349/7349

Phase I – Create IKE SA

• Negotiate protection suite• Use Diffie-Hellman to establish shared

secret– 3 groups of DH defined

• Authenticate the shared secret , IKE SA– Preshared keys (secret)– Digital signatures– Public-keys

SMU CSE 5349/7349

IKE Modes

• Phase I– Main Mode – flexible, 6 messages

• Checks cookies before DH work

– Aggressive mode – faster, 3 messages• Open to DoS, doesn’t check cookie before DH

work• Used mostly for remote access

• Phase II – Quick mode

SMU CSE 5349/7349

Oakley Key Exchange

• Designed to – Leverage advantages of DH

• Fresh keys• Secret never on the transit

– Counter DH weaknesses• No information on the Ids of the parties• Man-in-the-middle attack• Computationally intensive

SMU CSE 5349/7349

Oakley - Major Features

• Cookies to thwart DoS• Nonce to prevent replay• DH for key exchange• Authenticated key exchange• Specification of global parameters for

DH

SMU CSE 5349/7349

Cookies

• Requirements– Depend on specific parties– Only the issuing entity can generate

acceptable cookies – implies issuer using local secret

– Cookie generation and verification must be fast

• Suggested - Hash over IP Src/Dest; UDP Src/Dest; local secret

SMU CSE 5349/7349

SA, CKY-II R

Initiator Responder

SA, CKY-RNegotiate IKE SA parameters

NonceI, YI

NonceR, YR

IDI, HashI

IDR, HashR

Exchange items to generate secret

Send hash digest so peer can authenticate sender

Example: Main Mode Preshared

Generate SKEYID

SMU CSE 5349/7349

Phase II

• What traffic does SA cover ?• Initiator specifies which entries

(selectors) in SPD are for this IPSec SA, sends off to responder

• Keys and SA attributes communicated with the Phase I - IKE SA – Passes encrypted & authenticated

SMU CSE 5349/7349

HASH1, IPSec SA, NonceI, [New K]I R

Initiator Responder

HASH2, SA, NonceR, [New K]Negotiate IPSec SA Parameters, [PFS]

Example: Quick Mode

HASH3‘Liveness’ proof for Responder

SMU CSE 5349/7349

IKE Summary

smucse 5349/49 ip sec. smucse 5349/7349 basics network-level: all ip datagrams covered mandatory for...

Documents

source ip

ip headers

ip codebump

use sa

sa bundles

correct sa

sa bundleoutbound

ip header f