Network Security: IPsec

(1)

Network Security:

IPsec

Tuomas Aura

T-‐110.5241 Network security

Aalto University, Nov-‐Dec 2012

(2)

IPsec:

Architecture and protocols

(3)

Internet protocol security (IPsec)

!  

Network-‐layer security protocol

!  

Protects IP packets between two hosts or gateways

!  

Transparent to transport layer and applicaFons;

security policy deﬁned and enforced on network level

!  

IP addresses used to as host idenFﬁers

!  

Two steps:

1.  IKE authenFcated key exchange creates security associaFons 2.  ESP session protocol protects data

!  

Speciﬁed by Internet Engineering Task Force (IETF)

!  

Original goal: encrypFon and authenFcaFon layer that will replace all others

!  

Security (IPsec) was a sales point for IPv6, but it now works just

as well for IPv4

(4)

PAD PAD

!  

Security associaFons (SA) created by IKE, used by IPsec ESP

!  

Security policy guides SA creaFon and selecFon for use

!  

IPsec is part of the IP layer in the OS kernel; IKE is a user-‐space

IPSec IPSec

Node A Node B

1. Key exchange

2. ESP protects data

SPD

Security Policy Database

Untrusted network

SAD

Security Association

Database

Security Policy Database

SPD

SAD

Security Association

Database

IPsec SA Pair

Session Key

IKE(v2)

Session Key

IKE(v2)

IKE SA

IPsec architecture [RFC4301]

(5)

Internet Key Exchange (IKE)

!  

IKE(v1) [RFC 2407, 2408, 2409]

!   Framework for authenFcated key-‐exchange protocols, typically with Diﬃe-‐Hellman

!   MulFple authenFcaFon methods:

cerFﬁcates, pre-‐shared key, Kerberos

!   Two phases: Main Mode (MM) creates an ISAKMP SA (i.e. IKE SA) and Quick Mode (QM) creates IPsec SAs

!   Main mode (idenFty-‐protecFon mode) and opFmized aggressive mode

!   Interoperability problems: too complex to implement and test all modes; speciﬁcaFon incomplete

!  

IKEv2 [RFC 5996]

!   Redesign of IKE: fewer modes and messages, simpler to implement

!   IniFal exchanges create the IKE SA and the ﬁrst IPsec SA pair

!   CREATE_CHILD_SA exchange can create further IPsec SAs

!   EAP authenFcaFon for extensions

!  

Works over UDP port 500

(6)

Internet Key Exchange (IKEv2)

IniFal exchanges:

1. I → R: HDR(A,0), SAi1, KEi, Ni

2. R → I: HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

3. I → R: HDR(A,B), SK { IDi, [CERT,] [CERTREQ,] [IDr,] AUTHi, SAi2, TSi, TSr } 4. R → I: HDR(A,B), SK { IDr, [CERT,] AUTHr, SAr2, TSi, TSr }

A, B = SPI values that idenFty the protocol run and the created IKE SA Nx = nonces

SAx1 = oﬀered and chosen algorithms, DH group KEx = Diﬃe-‐Hellman public key (g^x or g^y)

IDx, CERT = idenFty, cerFﬁcate

AUTHi = Sign_I (Message 1, Nr, h(SK, IDi)) AUTHr = Sign_R (Message 2, Ni, h(SK, IDr))

SK = h(Ni, Nr, g^xy) — a bit simpliﬁed, 6 diﬀerent keys are derived from this SK { … } = E_SK( …, MAC_SK(…)) — MAC and encrypt with session key

SAx2, TSx = parameters for the ﬁrst IPsec SA (algorithms, SPIs, traﬃc selectors) CERTREQ = accepted root CAs (or other trust roots)

(7)

Internet Key Exchange (IKEv2)

IniFal exchanges:

2. R → I: HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

3. I → R: HDR(A,B), SK { IDi, [CERT,] [CERTREQ,] [IDr,] AUTHi, SAi2, TSi, TSr } 4. R → I: HDR(A,B), SK { IDr, [CERT,] AUTHr, SAr2, TSi, TSr }

A, B = SPI values that idenFty the protocol run and the created IKE SA Nx = nonces

SAx1 = oﬀered and chosen algorithms, DH group KEx = Diﬃe-‐Hellman public key (g^x or g^y)

IDx, CERT = idenFty, cerFﬁcate

AUTHi = Sign_I (Message 1, Nr, h(SK, IDi)) AUTHr = Sign_R (Message 2, Ni, h(SK, IDr))

SK = h(Ni, Nr, g^xy) — a bit simpliﬁed, 6 keys are derived from this SK { … } = E_SK( …, MAC_SK(…)) — MAC and encrypt

SAx2, TSx = parameters for the ﬁrst IPsec SA (algorithms, SPIs, traﬃc selectors) CERTREQ = accepted root CAs (or other trust roots)

Secret, fresh session key?

Mutual authenFcaFon?

EnFty authenFcaFon and key conﬁrmaFon?

Contributory?

Perfect forward secrecy?

Integrity check for iniFal negoFaFon?

Non-‐repudiaFon or plausible deniability?

IdenFty protecFon?

(8)

IKEv2 with a cookie exchange

!   In the second message, responder may send a cookie (a nonce)

!   Goal: prevent DOS aoacks from a spoofed IP address

2. R → I: HDR(A,0), N(COOKIE) // R stores no state 3. I → R: HDR(A,0), N(COOKIE), SAi1, KEi, Ni

4. R → I: HDR(A,B), SAr1, KEr, Nr, [CERTREQ] // R creates a state 5. I → R: HDR(A,B), SK{ IDi, [CERT,] [CERTREQ,] [IDr,]

AUTH, SAi2, TSi, TSr }

6. R → I: HDR(A,B), E_SK (IDr, [CERT,] AUTH, SAr2, TSi, TSr)

How to bake a good cookie? For example:

COOKIE = h(NR-‐periodic, IP addr of I, IP addr of R) where NR-‐periodic is a

periodically changing secret random value know only by the responder R

(9)

Security AssociaJons (SA)

!  

One IKE SA for each pair of nodes

!  

Stores the master key SK = h(Ni, Nr, g

^xy

) for creaFng IPsec SAs

!  

At least one IPsec SA pair for each pair of nodes

!  

Stores the negoFated session protocol, encrypFon and

authenFcaFon algorithms, keys and other session parameters

!  

Stores the encrypFon algorithm state

!  

IPsec SAs always come in pairs, one in each direcFon

!  

SAs are idenFﬁed by a 32-‐bit security parameter index (SPI) [RFC4301]

!  

The desFnaFon node selects the SPI value

!  

Node stores SAs in a security associaFon database (SAD)

(10)

Session protocol

§  Encapsulated Security Payload (ESP) [RFC 4303]

§  EncrypFon and/or MAC for each packet

§  OpFonal replay prevenFon with sequence numbers

§  Protects the IP payload (= transport-‐layer PDU) only

§  ESP with encrypFon only is insecure!

§  Old protocol: AuthenFcaFon Header (AH)

§  Do not use for new applicaFons

§  AuthenFcaFon only, no encrypFon

§  Protects payload and some IP header ﬁelds

(11)

Session protocol modes

!  

Transport mode:

!  

Host-‐to-‐host security

!  

ESP header added between the original IP header and payload

!  

Tunnel mode:

!  

Typically used for tunnels between security gateways to create a VPN

!  

EnFre original IP packet encapsulated in a new IP header plus ESP header

!  

In pracFce, IPsec is mainly used in tunnel mode

!   Proposed BEET mode:

!  Like tunnel mode but inner IP header not sent explicitly

!  Transport-‐mode headers but tunnel mode semanFcs

(12)

Session protocol modes

Transport mode

EncrypFon and/or authenFcaFon from end host to end host

Encrypted

Tunnel mode

EncrypFon and/or authenFcaFon between two gateways (VPN)

Encrypted

IPsec gateway IPsec gateway

Intranet Intranet

Internet Network

(13)

Using tunnel mode with hosts

Tunnel mode -‐ between end hosts (security equivalent to transport mode)

Network

Tunnel mode -‐ between a host and a gateway (typical VPN connecFon)

Intranet Internet

Untrusted access network

IPsec gateway

(14)

Nested tunnel and transport mode (less common but possible)

Nested protecJon

IPsec gateway IPsec gateway

IPsec gateway

Intranet Internet

Intranet Intranet

Internet

Untrusted access network

(15)

ESP packet format

IP header ESP header IP header

Original

Encrypted Original

Original

IP header IP Payload

ESP in transport mode:

ESP in tunnel mode:

Auth trailer ESP trailer

Encrypted AuthenFcated

ESP header and trailer =

SPI + Sequence number + Padding ESP authenFcaFon trailer =

message authenFcaFon code (MAC)

Original packet:

IP header ESP header IP Payload ESP trailer Auth trailer

IP Payload

!

(16)

ESP packet format (2)

!   ESP packets in a more abstract notaFon:

!   Transport mode headers:

IP(src host, dst host)|ESP|payload

!   Tunnel mode headers:

IP(src gw, dst gw)|ESP|IP(src host,dst host)|payload

(17)

IPsec databases

!  

Security associaFon database (SAD)

!   Contains the IPsec SAs i.e.t the dynamic protecFon state

!  

Security policy database (SPD)

!   Contains the staFc security policy

!   Usually set by system administrators (e.g. Windows group policy), although some protocols and applicaFons make dynamic changes

!  

Peer authorizaFon database (PAD)

!   Needed in IKE for mapping between authenFcated names and IP addresses

!   Conceptual; not implemented as an actual database

!  

AddiFonally, the IKE service/daemon stores IKE SAs:

!   Master secret created with Diﬃe-‐Hellman key exchange

!   Used for instanFaFng new IPsec Sas

(Note: our descripFon of SPD diﬀers somewhat from RFC4301 and is probably closer to most implementaFons)

(18)

Gateway SPD/SAD example

Protocol Local IP Port Remote IP Port AcFon Comment

UDP 2.3.4.5 500 4.5.6.7 500 BYPASS IKE

* 1.2.3.0/24 * 5.6.7.0/24 * ESP tunnel to 4.5.6.7 Protect VPN traﬃc

* * * * * BYPASS All other peers

SPI SPD selector

values Protocol Algorithms, keys,

algorithm state spi1 UDP, 1.2.3.0/24, 5.6.7.0/24 ESP tunnel from 4.5.6.7 …

spi2 — ESP tunnel to 4.5.6.7 …

Intranet 1.2.3.0/24

2.3.4.5 1.2.3.1

interface1

5.6.7.1 4.5.6.7

Intranet 5.6.7.0/24

Internet

interface2 interface1 interface2

SPD of gateway A, interface 2

SAD of gateway A

(19)

Security policy database (SPD)

!   Speciﬁes the staFc security policy

!   MulF-‐homed nodes have a separate SPD for each network interface

(in pracFce, they can be stored on one database)

(mulFhomed = node with mulFple network interfaces)

!   Policy maps inbound and outbound packets to acFons

!  SPD = linearly ordered list of policies

!  Policy = selectors + acFon

!  The ﬁrst policy with matching selectors applies to each packet

!   Policy selector is a 5-‐tuple:

!  Local and remote IP address

!  Transport protocol (TCP, UDP, ICMP)

!  Source and desFnaFon ports

!   AcFons: BYPASS (allow), DISCARD (block), or PROTECT

!  PROTECT speciﬁes also the session protocol and algorithms

!  Packet is mapped to a suitable IPsec security associaFon (SA)

!  If the SA does not exist, IKE is triggered to create them

!  SPD stores pointers to previously created SAs

!   Policies at peer nodes must match if they are to communicate

(20)

Security associaJon database (SAD)

!   Contains the dynamic encrypFon and authenFcaFon state

!   IPsec SAs always come in pairs: inbound and outbound

!   SAD is keyed by SPI (for unicast packets)

!   SAs are typically created by IKE but they may also be conﬁgured manually or by other soxware,

e.g. to create ﬁxed VPN tunnels

!   Each SAD entry remembers also the policy selector

values that were used when creaFng it

(21)

Gateway SPD/SAD example

UDP 2.3.4.5 500 4.5.6.7 500 BYPASS IKE

* 1.2.3.0/24 * 5.6.7.0/24 * ESP tunnel to 4.5.6.7 Protect VPN traﬃc

* * * * * BYPASS All other peers

SPI SPD selector

values Protocol Algorithms, keys,

algorithm state spi1 UDP, 1.2.3.0/24, 5.6.7.0/24 ESP tunnel from 4.5.6.7 …

spi2 — ESP tunnel to 4.5.6.7 …

Intranet 1.2.3.0/24

Intranet 5.6.7.0/24

Internet

SPD of gateway A, interface 2

SAD of gateway A

(22)

Host SPD example

!   SPD for host 1.2.3.101 in intranet 1.2.3.0/24, connecFng to server 1.2.4.10 in network 1.2.4.0/24 (DMZ) and to the Internet

UDP 1.2.3.101 500 * 500 BYPASS IKE

ICMP 1.2.3.101 * * * BYPASS Error messages

* 1.2.3.101 * 1.2.3.0/24 * PROTECT: ESP in

transport-‐mode Encrypt intranet traﬃc

TCP 1.2.3.101 * 1.2.4.10 80 PROTECT: ESP in

transport-‐mode Encrypt to server TCP 1.2.3.101 ≥1024 1.2.4.10 443 BYPASS Allow TLS, no

double encrypFon

* 1.2.3.101 * 1.2.4.0/24 * DISCARD Others in DMZ

* 1.2.3.101 * * * BYPASS Internet

!   What is the danger of bypassing TLS traﬃc (line 5)?

!   What is the danger of bypassing outbound ICMP (line 2)?

Note that the other endpoint (other intranet hosts and 1.2.4.10) must have an

(23)

IPsec policy implementaJon diﬀerences

!  

Historically, IPsec and ﬁrewalls have diﬀerent models of the network:

!  Firewall is a packet ﬁlter: which packets to drop and which to allow?

!  IPsec sits between the secure and insecure areas (host and network at IPsec hosts, intranet and Internet at IPsec gateways) and encrypts packets that leave the secure side

Firewall and IPsec policies can, however, be uniﬁed

!  

In some IPsec implementaFons, the policy is speciﬁed in terms of source and desFnaFon addresses (like a typical ﬁrewall policy), instead of local and remote addresses

→ mirror ﬂag is shorthand notaFon to indicates that the policy applies also with the source and desFnaFon reversed

Mirror Protocol Source IP Port DesFnaFon IP Port AcFon Comment yes UDP 2.3.4.5 500 4.5.6.7 500 BYPASS IKE

yes * 1.2.3.0/24 * 5.6.7.0/24 * ESP tunnel to

4.5.6.7 Protect VPN traﬃc

(24)

Outbound packet processing

!  

Processing outbound packets in IPsec:

1.  For each outbound packet, IPsec ﬁnds the ﬁrst matching policy in the security policy database (SDP)

2.  If the policy requires protecFon, IPsec maps the packet to the right security associaFon (SA) in the SA database (SAD)

3.  If no SA exists, IPsec invokes the IKE service (running in user space) to create a new SA pair

4.  While waiFng for the IPsec SA, at most one outbound packet (oxen TCP SYN) is buﬀered in the kernel

5.  When the SA exists, the packet is encrypted and a MAC added

(25)

Inbound packet processing

!  

Processing inbound IPsec packets:

1.  IPsec looks up the inbound SA in SAD based on the SPI

2.  IPsec processes the packet with the SA, i.e. veriﬁes the MAC and decrypts

3.  IPsec compares the packet with the selector values that were used when creaFng this SAD entry. For tunnel-‐mode packets, the comparison is done with the inner IP header

!  

Processing of inbound non-‐IPsec packets:

!  

IPsec ﬁnds the ﬁrst matching policy in the SPD and checks that the acFon is BYPASS

!  

If the acFon is not BYPASS, the packet is dropped

!  

In Windows, it is possible to allow the ﬁrst inbound packet (oxen TCP SYN) to bypass IPsec. The outbound response will trigger IKE

Helps in gradual deployment of host-‐to-‐host IPsec

(26)

Some problems with IPsec

(27)

IPsec and NAT

!   Problems:

!  

NAT cannot mulFplex IPsec: impossible to modify SPI or port number because they are authenFcated

→ Host behind a NAT could not use IPsec

!   NAT traversal (NAT-‐T):

!  

UDP-‐encapsulated ESP (port 4500)

!  

NAT detecFon: extension of IKEv1 and IKEv2 for sending the original source address in iniFal packets

→ Enables host behind a NAT to use IPsec

(28)

IPsec and mobility

!  

Problem:

IPsec policies and SAs are bound to IP addresses. Mobile nodes change their IP address

!  

Mobile IPv6 helps: home address (HoA) is stable. But Mobile IPv6 itself depends on IPsec for the tunnel between HA and MN. → Chicken-‐and-‐egg problem

!  

SoluFons:

!  

IPsec was changed to look up inbound SAs by SPI only

!  

IPsec-‐based VPNs from mobile hosts do not use the IP address as selector. Instead, proprietary soluFons

!  

MOBIKE mobility protocol

(29)

IPsec and IdenJﬁers

!   ApplicaFon opens a connecFon to an IP address.

IPsec uses the IP addresses as policy selector

!   IKE usually authenFcates the remote node by its DNS name

!   Problem: No secure mapping between the two

idenFﬁer spaces: DNS names and IP addresses

(30)

IPsec and name resoluJon

! Typical TCP socket API use: resolve name into an IP address; then connect to the address

!   TCP SYN to the address triggers IKE (if the ESP SA does not exist yet)

2. Key Exchange (IKE) IP Network

PC-A

Name service

Server-B 1.2.3.4 Application Data

Query: “server-b”

Response: “1.2.3.4”

1. Name resolution

3. IPsec Protection OS

Application

IPsec Policy:

1.2.*.* ESP

* BYPASS

(31)

Classic IPsec/DNS Vulnerability

!  

IPsec policy selecFon depends on secure name resoluFon

2. Key Exchange (IKE) Honest host

Attacker pc-c.example.org

3.4.5.6 Application Data

Query: “server-b.example.org”

Spoofed Response: “3.4.5.6”

Application

IPsec Policy

1.2.*.* ESP * BYPASS

(32)

IPsec and CerJﬁcates

!   Let’s assume DNS is secure

!   Another problem: IKE knows the peer IP address, not the peer name;

the cerFﬁcate only contains the name

à How does IPsec decide whether the cerFﬁcate is ok?

2. Key Exchange (IKE) Honest host

Name service Query:

“server-b.

example.org”

Response:

“1.2.3.4”

OS Application

“1.2.3.4” =

“server-b” ?

“1.2.3.4”

Certificate:

{“server-b.example.org”, PublicKeyC}CA

“server-b.

example.org”

Connect(“1.2.3.4”)

(33)

! What can go wrong?

2. Key Exchange (IKE) Certificate:

{“server-b”, PublicKeyB}CA PC-A

Name service Application Data

Response: “1.2.3.4”

Application

IPsec Policy:

* ESP

Server-B 1.2.3.4

(34)

IPsec and CerJﬁcates -‐ AYack

!   IPsec cannot detect whether the cerFﬁcate contains the correct name

!   Secure DNS (forward lookup) does not help — why?

!   Result: group authenFcaFon of those cerFﬁed by the same CA

→ maybe ok for protecFng an intranet where the goal is to keep outsiders out

2. Key Exchange (IKE) Certificate:

{“pc-c”, PublicKeyC}CA PC-A

Name service Application Data

Response: “1.2.3.4”

Application

IPsec Policy:

* ESP

Attacker PC-C (using 1.2.3.4)

(35)

Peer authorizaJon database (PAD)

!  

IPsec spec [RFC4301] deﬁnes a database that maps

authenFcated names to the IP addresses which they are allowed to represent

!  

How implemented? Secure reverse DNS would be the best soluFon — but it does not exist

!  

Other soluFons:

!  

Secure DNS — both secure forward and reverse lookup needed, which is unrealisFc

!  

Give up IPsec transparency — extend the socket API so that applicaFons can query for the authenFcated name and other security state

!  

Connect by name — change the socket API so that the connect() call speciﬁes the host name, not the IP address

!  

Currents situaFon: IPsec is only used for VPN where the

gateway names and IP addresses are preconﬁgured

(36)

!   William Stallings. Network security essenFals:

applicaFons and standards, 3rd ed. chapter 6; 4th ed. chapters 8, 11

!   William Stallings. Cryptography and Network Security, 4th ed.: chapter 16

!   Kaufmann, Perlman, Speciner. Network security, 2nd ed.: chapter 17 (ignore AH)

!  

Note: chapter 18 on the older IKEv1 is historical

!   Dieter Gollmann. Computer Security, 2nd ed.

chapter 13.3; 3rd ed. chapters 16.1–16.3, 17.3

(37)

Exercises

!   Why is IPsec used mainly for VPN implementaFons? Does IPsec VPN suﬀer from any of the problems menFoned in the lecture?

!   For the IPsec policy examples of this lecture, deﬁne the IPsec policy for the peer nodes i.e. the other ends of the connecFons.

!   Try to configure the IPsec policy between two computers. What difficulFes did you meet? Use ping and TCP to test connecFvity. Use a network sniffer to observe the key exchange and to check that packets on the wire are encrypted.

!   What administraFve problems arise from the fact that IPsec security policies in two communicaFng nodes must match? How is this solved in Windows?

!   RFC 4301 requires that the SPD is decorrelated, i.e. that the selectors of policy entries not to overlap, i.e. that any IP packet will match at most one rule (excluding the

default rule which matches all packet). Yet, the policies created by system

administrators almost always have overlapping entries. Device an algorithm for transforming any IPsec policy to an equivalent decorrelated policy. (Real protocol stacks do not implement decorrelaFon. Why?)

!   Each SAD entry stores (caches) policy selector values from the policy that was used when creaFng it. Inbound packets are compared against these selectors to check that the packet arrives on the correct SA.

!  What security problem would arise without this check?

!  What security weakness does the caching have (compared to a lookup through the SPD)?

!  Does policy decorrelaFon solve the problem?

Network Security: IPsec