Sie sind auf Seite 1von 52

IP Sec

SMU CSE 5349/49


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


Tunnel vs. Transport Mode

Encrypted Tunnel

Gateway Gateway

Encrypted Unen
ry pted crypt
ed
A Une
nc B

New IP AH or ESP Orig IP TCP Data


Header Header Header

SMU CSE 5349/7349


Transport Mode Security

IP IP IPSec Higher
header options header layer protocol

Real IP ESP
destination
AH

• ESP protects higher layer payload only


• AH can protect IP headers as well as
higher layer payload
SMU CSE 5349/7349
Tunnel Mode Security

Outer IP IPSec Inner IP Higher


header header header layer protocol

Destination ESP Real IP destination


IPSec
entity
AH

• ESP applies only to the tunneled packet


• AH can be applied to portions of the outer
SMU
header 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


Outbound Processing
Outbound packet (on A)
A B
IP Packet
SPD SA
(Policy) Database
Is it for IPSec?
If so, which policy
entry to select?

IPSec processing

… … SPI & IPSec


Determine the SA Packet
and its SPI

SMU CSE 5349/7349


Send to B
Inbound Processing

Inbound packet (on B) A B

From A
SA Database SPD
SPI & Packet
(Policy)
Use SPI to Was packet properly
index the SAD secured?

Original IP Packet

SMU CSE 5349/7349


Authenticated Header (AH)

SMU CSE 5349/49


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

Next Header Payload Length


(TCP/UDP) Reserved
SPI

Sequence Number

ICV

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!

Check bitmap, verify if new


reject verify
Sliding Window
0 size >= 32
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/7349


Encapsulated Security Protocol (ESP)

SMU CSE 5349/49


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


ESP Transport Example
Original IP Header

Authentication coverage SPI


Sequence Number

Payload (TCP Header and Data)


Encrypted

Variable Length

Padding (0-255 bytes)


Pad Next
Length Header

Integrity Check Value


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


Internet Key Exchange (IKE)

SMU CSE 5349/49


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


Initiator Responder
SA, CKY-I
I Negotiate IKE SA
R
parameters
SA, CKY-R

NonceI, YI
Exchange items to
NonceR, YR generate secret

Generate SKEYID
IDI, HashI
Send hash digest so peer
can authenticate sender IDR, HashR

Example: Main Mode Preshared


SMU CSE 5349/7349
Main Mode Preshared

• PRF, Pseudo-Random Function


• SKEYID root secret
=PRF(preshared-key,Ni|Nr)
• SKEYID_d for IPSec SA
=PRF(SKEYID,K|CKY-I|CKY-R|0)
K is the secret generated by DH
• SKEYID_a for IKE message data auth & integrity
= PRF(SKEYID,SKEYID_d|K|CKY-I|CKY-R|1)
• SKEYID_e use to encrypt IKE messages
= PRF(SKEYID,SKEYID_a|K|CKY-I|CKY-R|2)
SMU CSE 5349/7349
Main Mode Preshared Hashes

• To authenticate each other, each entity


generates a hash digest that only the peer
could know
Hash-I=PRF(SKEYID,YI|YR|CKY-I|CKY-R|SA Offer|ID-I)
Hash-R =PRF(SKEYID,YR|YI|CKY-R|CKY-I|SA Offer|ID-R)

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


Example: Quick Mode

Initiator Responder

HASH1, IPSec SA,


I NonceI, [New K] R

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

HASH3
‘Liveness’ proof for
Responder

SMU CSE 5349/7349


IKE Summary

SMU CSE 5349/7349

Das könnte Ihnen auch gefallen