IPsec and Secure VPNsdiscipline.elcom.pub.ro/cscn/project/CSCN_intro-to-ipsec.pdf · Cryptography and Security in Communication Networks IPsec and Secure VPNs (self study for project)

Cryptography and Security in Communication Networks

IPsec and Secure VPNs (self study for project)

ETTI - Master - Advanced Wireless Telecommunications

© Octavian Catrina 2

Virtual Private Networks (VPN)

Private, public, virtual private networks

Private network: Owned and managed by a company, used for

its own communications.

Public network: Owned and managed by a network service

provider, used to offer communication services to customers.

Virtual private network: Extension of a private network using a

public telecommunication infrastructure.

VPN requirements Security: Confidentiality, integrity, access control.

Quality of Service: Availability. Performance: bandwidth, delay.

Low cost: Installation, operation.

1 Public network 2

Private network Private network Virtual Private Network

Main VPN scenarios


1

Internet

Remote access VPN:

Access to corporate intranet

BobSoft Inc. headquarters:

Corporate intranet

BobSoft branch office networks:

Connected to the corporate intranet

Bob at home, hotel, airport, ...

2 Site-to-site VPN:

Interconnects different sites

of the corporate intranet

3 Alice Consulting

Extranet VPN:

Remote access for

business partners

Private network Private network

Private network

BobSoft's VPN

Site-to-site VPN Interconnects geographically dispersed private networks.

Intranet: all sites have the same owner (corporate branches).

Extranet: sites have different owners (business partners).

Remote-access VPN Provides access to the company's intranet to a mobile user,

home user, etc. Different requirements and technologies.

VPN categories: Secure VPN


1

Internet

Remote access secure VPN:

Secure access to corporate intranet

BobSoft Inc. headquarters:

Corporate intranet

BobSoft branch office networks:

Connected to the corporate intranet

Bob at home, hotel, airport, ...

2 Site-to-site secure VPN:

Secure interconnection

of private networks

3 Alice Consulting

Extranet VPN:

Secure remote access

for business partners

Private network Private network

Private network

BobSoft's secure VPN

Strong security using cryptographic protocols

Trusted VPN solutions cannot offer strong security (data

privacy and integrity, authentication and authorization).

Secure VPNs use cryptographic protocols that set up secure

channels (authenticated and encrypted) across the Internet.

Issues: Scalability (cryptographic overhead), QoS, higher costs.

Secure channels using

cryptographic protocols:

data integrity,

authentication,

confidentiality


Secure VPNs using IPsec

IPsec: IP security

Suitable for both site-to-site and remote-access VPNs.

Creates secure channels available for all IP applications,

between: hosts, entire networks, a host and a network.

Available for both IPv4 and IPv6.

Layer 2 Tunneling Protocol (L2TP)

Creates a tunnel and offers PPP features needed for remote

access: IP protocol configuration (address, DNS, etc.), user

authentication, data and header compression, etc.

Security provided by IPsec. Solution preferred by Microsoft.

Some IPsec disadvantages

Conflicts with anything that tries to inspect and/or modify

protected IP payload or header (encrypted, authenticated):

NAT, firewall, IP QoS (workarounds available).

A VPN client must be installed on the users' computers.


IPsec VPNs

Tunnel mode: IPsec payload is the entire IP packet. It is delivered

encapsulated in another IP packet (IP tunnel). Used for gateway-

to-gateway or host-to-gateway secure channels.

Transport mode: IPsec payload is the IP packet payload. Can be

used for end-to-end (host-to-host) security.

Also used to secure communications within a private network.

1

Internet

IP header

IPSec header

Protected payload

IP header

IP payload

IP header

IP payload

IP header

IPSec header

Protected payload

Remote access VPN

BobSoft Inc. headquarters

Corporate intranet

BobSoft branch office network

(connected to corporate intranet)

Bob at home, airport, ...

IP header

IP payload

2

3

Trudy

Extranet VPN

Site-to-site VPN

Alice Consulting

Business partner

IPsec IP Security protocols


IPsec protocols and services

Encapsulating Security Payload (ESP) protocol

Encryption and/or authentication: full IP packet or IP payload.

Authentication Header (AH) protocol

Authentication: full IP packet or IP payload; fixed header fields.

Internet Key Exchange (IKE) protocol

Security association and key management.

AH or/and ESP?

Do we really need AH, besides ESP? Many believe we don't ...

We can use ESP for data authentication only, without encryption. However, AH

also protects the header. We could also use them together, but it is inefficient.

Summary of security services

Data origin authentication. Data confidentiality. Access control.

Partial packet flow integrity: Connectionless packet integrity.

Anti-replay protection. Limited traffic flow confidentiality.


Authenticated encryption

Authenticated encryption Combination of encryption and message authentication.

Never use encryption without (data) authentication. If

confidentiality is not necessary, use MAC alone.

Composition of MAC and encryption schemes

Variant Protected message Example Provable security

Encrypt then MAC

(ETM)

EK1(m) || MACK2(EK1(m)) IPsec Secure composition independent of

schemes. Recommended method.

MAC then Encrypt

(MTE)

EK1(m || MACK2(m)) TLS Secure composition for certain (usual)

combinations of schemes.

MAC and Encrypt

(MAE)

EK1(m) || MACK2(m) SSH Not provable as general composition

method (secure in particular cases).

Dedicated authenticated-encryption schemes More efficient than composition techniques. Examples:

CCM (Counter with CBC-MAC Mode), NIST SP800-38C. E.g., IEEE 802.11i.

GCM (Galois/Counter Mode), NIST SP800-38D. E.g., IEEE 802.1ae.


Brief chronicle of IPsec

The beginning IPsec development and standardization started in 1992.

First specifications were published in 1995.

IPsec Architecture, Authentication Header (AH), and Encapsulated

Security Payload (RFC 1825-1827). No Internet Key Exchange (IKE).

Second iteration Revised IPsec specifications were published in 1998.

Architecture, AH, ESP (RFC 2401, 2402, 2406); and others.

A first specification for IKE: IKEv1 (RFC 2407, 2408, 2409).

This version was widely deployed, although IKEv1 was a flop.

Work on IKEv2 started soon afterwards.

Current specs Revised IPsec specifications finally issued at the end of 2005.

Architecture, AH, ESP (RFC 4301-4303); and others.

Substantial redesign of IKE: IKEv2, RFC 4306.


Encapsulating Security Payload (ESP)

Encrypted and authenticated payload.

Transport mode: IPsec Payload Data is the

IP packet payload. IP header not protected.

Tunnel mode: IPsec Payload Data is the

entire IP packet.

Encryption. E.g., AES in CBC or CTR mode.

ICV = MAC. E.g., HMAC-SHA1, AES-XCBC.

32 bits

Au

the

nti

ca

ted

En

cry

pte

d

Encapsulating

Security

Payload

SPI (Security Parameters Index)

Sequence Number

Integrity Check Value (ICV)

(variable length, default 96 bits)

Payload Data (variable length)

Pad Length

Padding (0-255 bytes)

Next Header

IP Header

with Protocol ID field = ESP

IV (Initialization Vector, if necessary; variable length)

Security Parameters Index (SPI): Identifies

the IPsec Security Association (SA) for

this packet at the receiver.

Next Header: Protocol ID of Payload Data.

Sequence Number: Anti-replay protection.

Padding: Values 1, 2, …, Pad Length. To

multiple of 32 bits and (for some schemes)

of block length; may hide payload length.


ESP: Transport mode, Tunnel mode

ESP in Tunnel mode

R1 R2 H1 H2

IP header H1H2

IP payload

IP header H1H2

IP payload

IP header R1R2

ESP header

IP header H1H2

IP payload

ESP trailer

ESP ICV

ESP in Transport mode

R1 R2 H1 H2 IP header H1H2

ESP header

IP payload

ESP trailer

ESP ICV

IP header H1H2

ESP header

IP payload

ESP trailer

ESP ICV

IP header H1H2

ESP header

IP payload

ESP trailer

ESP ICV

Without IPSec

R1 R2 IP header H1H2

IP payload

IP header H1H2

IP payload

IP header H1H2

IP payload

H1 H2

Can set up tunnels between hosts or gateways.

Must use tunnel if an endpoint is gateway.

Main use is gateway (or remote host) to gateway.

Encrypted and authenticated

Authenticated only

Authentication Header (AH)


32 bits

SPI (Security Parameters Index)

Sequence Number

Integrity Check Value (ICV)

(variable length, default 96 bits)

Next Header Payload length Reserved

IP Header

Payload

Authentication

Header

with protocol id field = AH Partially

Authenticated

Authenticated

Authenticated payload and fixed header fields.

Transport mode: IPsec Payload Data is the

IP packet payload. IP header not protected.

Tunnel mode: IPsec Payload Data is the

entire IP packet.

ICV = MAC. E.g., HMAC-SHA1, AES-XCBC.

Security Parameters Index (SPI): Identifies

the IPsec Security Association (SA) for

this packet at the receiver (SA records AH

or ESP protocol, crypto schemes, keys).

Next Header: Protocol ID of Payload Data.

Sequence Number: Anti-replay protection.


AH: Transport mode, Tunnel mode

AH in Tunnel mode

R1 R2 H1 H2

IP header H1H2

IP payload

IP header H1H2

IP payload

IP header R1R2

AH header

IP header H1H2

IP payload

AH in Transport mode

R1 R2 H1 H2

IP header H1H2

AH header

IP payload

IP header H1H2

AH header

IP payload

IP header H1H2

AH header

IP payload

Without IPSec

R1 R2 IP header H1H2

IP payload

IP header H1H2

IP payload

IP header H1H2

IP payload

H1 H2

Can set up tunnels between hosts or gateways.

Must use tunnel if an endpoint is gateway.

Main use is gateway (or remote host) to gateway.

Authenticated

Partially authenticated


Transport mode vs. Tunnel mode

IPSec Transport Mode

Advantages

End-to-end (host-to-host) protection. ESP encrypts and authenticates payload. AH authenticates payload and IP header fields.

Lower encapsulation overhead. Adds only AH header or ESP header and trailer.

Disadvantages

Requires a security association per pair of hosts. Not appropriate for inter-site VPN: does not scale up for any-to-any communications.

Does not hide IP header. ESP does not protect the IP header at all. AH only authenticates it.

Requires IPSec processing at hosts (not transparent for hosts). Hosts must know IPSec. Processing overhead.

IPSec Tunnel Mode

Advantages

A tunnel between gateways protects all traffic between 2 networks. Good for site-to-site VPN or remote access VPN (remote host to gateway).

Can encrypt IP header and payload (ESP). ESP protected packet is encapsulated as payload in outer IP packet.

Good for security, but can hinder other functions (e.g., end-to-end QoS).

Tunnel between gateways is transparent for hosts. Hosts need not know IPSec.

Disadvantages

Tunnel between gateways does not offer end-to-end protection.

Higher encapsulation overhead.

Adds outer IP header, besides AH header or ESP header and trailer.


Anti-replay service

AH and ESP provide an "anti-replay" service

Receiver rejects replayed packets (partial sequence integrity).

Uses 32-bit sequence numbers in AH and ESP headers.

Sender behavior

The sender initializes a sequence counter to 0 and increments

it for each datagram sent.

The sender cannot continue to send if the counter overflows.

In this case the security association is re-established.

Receiver behavior

The receiver discards a packet if it carries a sequence number

equal to that of another packet received during the current

security association.

(Actually, it records recently received sequence numbers

within a sliding window of convenient size, e.g., 64).


Security associations

Security association (SA)

One-way relationship between a sender and a receiver which

defines the security services offered and their parameters.

SA identification

Security parameters index (SPI).

Carried in ESP and AH headers. Used by a receiver

to select the SA corresponding to a received packet.

Packet destination address.

Security protocol identifier: ESP or AH.

SA Parameters (selection)

AH information (for an AH SA): MAC algorithm,

keys, initialization values.

ESP information (for an ESP SA): encryption and

MAC algorithms, keys, initialization values.

Protocol mode: transport/tunnel.

Sequence number counter.

Anti-replay window.

SA lifetime.

Hosts

or

routers

Hosts

or

routers

SA database SA database

. . . . . .

See RFC 4301


Security policies 1/2

Security Policy Database (SPD)

Every inbound or outbound IP packet is subject to processing

by IPsec. SPD specifies what security services have to be

offered and how, for every packet.

There is (conceptually) an SPD for each interface, for inbound

packets, and for outbound packets.

SPD contains an ordered list of policy entries. A policy specifies

traffic selectors and actions to be taken for matching packets.

SPD policy: Traffic selectors

Packet filters that select the packets to which a policy applies.

Defined based on:

Source and destination IP addresses.

Protocol id.

Source and destination ports.

Source and destination names (e.g., DNS).


Security policies 2/2

SPD policy: Actions

Possible actions: discard, bypass, protect.

Discard (packet)

Do not let the packet in or out.

Bypass (IPsec)

Outbound packet: do not apply IPsec.

Inbound packet: do not expect IPsec.

Protect (packet)

If the SPD entry points to an SA (or SA bundle):

Outbound packet: Apply security as specified in SA.

Inbound packet: Check that security has been applied.

If an SA does not exist:

Outbound packet: use IKE to create a new SA.

Inbound packet: discard the packet.


Discard IPSec

packet if SA not found, verification fails, ...

Find matching

SP in SPD

Packet processing (outline)

Example: ESP transport mode.

Host or

router X

Host or

router Y

SAD (assoc.) SPD (policies)

Outbound packet

IP header XY

IP payload

If IPSec protected

packet, get its SA

IPSec trs.

processing

. . .

ESP, TR ...

Inbound packet

. . .

ESP, TR ...

AH/ESP

SPI, DA

SAD (assoc.) SPD (policies)

IPSec rec.

processing

Find & check

matching SP

IP header XY

IP payload

IP header XY

ESP header

IP payload

ESP trailer

If AH/ESP, find

matching SA

IP header XY

ESP header

IP payload

ESP trailer

. . .

DA=Y ... SA

. . .

DA=Y ... SA

SP = Security Policy

SPD = Security Policy Database

SA = Security Association

SAD = Security Association Database

Set up new SA if

IPSec is required

and SA not found

IPSec SA

See RFC 4301


Examples

End-to-end security between 2 hosts

Transport mode or tunnel mode.

# Protocol Transport mode

1 AH [IP1][AH][upper]

2 ESP [IP1][ESP][upper]

3 AH + ESP [IP1][AH][ESP][upper]

# Protocol Tunnel mode

4 AH [IP2][AH][IP1][upper]

5 ESP [IP2][ESP][IP1][upper]

Site-to-site VPN (intranet/extranet) Tunnel mode.

Can also set up nested tunnels,

possibly with different endpoints.

SG1 SG2 H1 H2

SG = IPsec VPN Gateway

Internet

Security Association - Tunnel mode

IP IP IPsec

Internet or

Intranet H1 H2

Security Association

IPsec

Transport (or Tunnel) mode

IP1 = Original IP header

IP2 = Tunnel IP header

Upper = Original IP payload

Encapsulation


More examples

Remote access VPN

Tunnel mode (possibly combined with transport mode).

Site-to-site VPN and end-to-end security

Intranet or extranet.

Tunnel mode combined with transport mode.

Internet

SG2 H1 H2

Security Association - Tunnel mode

Optional Security Association - Transport mode

IPsec

IP-sec

IP or

SG1 SG2 H1 H2

Internet

Security association - Tunnel mode

Security association - Transport mode

IPsec IP-sec IP-sec SG = IPsec

VPN Gateway

IKE Protocol Internet Key Exchange

Introduction


IKEv1 overview

IKEv1 (1998) description is spread over several RFCs... Start with:

RFC 2408: ISAKMP (Internet Security Association Key

Management Protocol). Generic framework.

RFC 2409: IKE (Internet Key Exchange).

RFC 2407: IPsec Domain Of Interpretation (DOI) for ISAKMP.

IKEv1 is a mixture of several protocol proposals ... Quotes from RFC 2409: "This document describes a protocol using part of Oakley and part of SKEME

in conjunction with ISAKMP... While Oakley defines "modes", ISAKMP defines

"phases". The relationship between the two is very straightforward and IKE

presents different exchanges as modes which operate in one of two phases ..."

it is by far too complex ... E.g., main mode and aggressive mode, with 4 different

variants: 8 (eight) protocol variants just for creating an IKE SA.

and has some design flaws.


Overview: SA management

IKEv1 SA management

A security association defines the parameters for a single

protocol: IKE or AH or ESP.

IKE starts by establishing an IKE SA (Phase 1).

The IKE SA is a secure channel used to set up efficiently

children SAs, which are AH SA or ESP SA (Phase 2), and for

other SA management tasks (re-keying, error/status, delete).

Negotiation of SA attributes

IKE allows the selection of the cryptographic algorithms and

their parameters, separately for each SA.

Algorithms that are negotiated: encryption, MAC, Diffie-Hellman

group (global parameters), PRF (pseudorandom function), etc.

The PRF (based on MAC) is used to generate the shared keys

from the exchanged key material, for IKE SA and children SAs.


Overview: Key exchange

Security requirements

Authenticated key exchange with mutual authentication.

PFS, identity hiding, (some) protection against DoS attacks.

Key generation

Distinct sets of keys are established for the IKE SA and for

each of the children SA.

Keys are different for each direction of data flow and for each

algorithm (MAC and encryption).

All these keys are obtained using PRF from the random key

material exchanged by IKE (DH exponentials and nonces).

IKE messages transport

IKE messages are delivered using UDP.

IKE entities send and receive using UDP port number 500.


IKE design: Identity hiding 1/2

Authenticated key exchange with identity hiding

Some application scenarios require the protection of endpoint

identities during key exchange, against passive/active attacks.

E.g., hide identity info provided in public-key certificates.

Conflicting requirements: authentication vs. identity hiding.

What protection can be achieved?

Hide initiator and responder identity against passive attacks.

Hide either initiator, or responder identity against active attacks.

SIGA(A | B | gx | gy)

A B

A, gx

B, gy, SIGB(B | A | gy | gx) Authenticate B.

Compute keys

K = PRF(gxy).

Choose random DH

exponent y, ...

Choose random DH exponent x, …

Compute keys

K = PRF(gxy).

Authenticate A.

Example: AKE protocol that does NOT hide identities

DH with authentication based on SIG.

Identity hiding 2/2


EK1A{A, SIGA(gx | gy), MACK2A(A)}

A B

gx

gy, EK1B{B, SIGB(gy | gx), MACK2B(B)}

Choose random DH

exponent y, compute gy.

Choose random DH exponent x, compute gx

Compute keys: PRF(gxy) =

K1A | K2A | K1B | K2B.

Authenticate peer and avoid

active attacks using SIG and

MAC. Use (authenticated)

encryption to hide identity.

In the previous variant, signing the peer's identity avoids identity

misbinding attacks. But that solution does not allow identity hiding.

In SIGMA, the attacks are avoided by using a MAC of the sender's

identity, which proves knowledge of the established key.

Encryption (authenticated) is added only to hide the identities.

This protocol hides both identities for passive attacks, and hides

the identity of the initiator for active attacks.

Example: AKE protocol that hides identities

DH with authentication based on SIG (and MAC).

SIGMA (SIGn and MAc) protocol.

Compute keys: PRF(gxy) =

K1A | K2A | K1B | K2B.

Authenticate peer and avoid

active attacks using SIG and

MAC. Use (authenticated)

encryption to hide identity. Variant (used in IKE): SIG(MAC(gx | gy | ID))


IKE design: Defense against DoS

Clogging protection

An adversary can mount a denial-of-service attack by sending a

large number of authentication requests. Typically the attacker

uses forged source IP addresses to hide his/her identity.

Defense (weak): Check if the initiator is indeed at the source IP

address in the request, before committing any resources.

Initiator Responder

gx (I want to talk)

cookie (Send back this cookie ...)

cookie, gx (Your cookie. My DH exp)

Stateless

Compute cookie c =

hash(secret, IP addr.).

If cookie = hash(secret, IP

addr.) continue protocol. . . .

This technique adds a round-trip delay. Should be optional:

Use it only when the responder detects a DoS attack.

Attacker can send

any string as "gx".

Example: Stateless "cookies" preamble


Towards real-life AKE protocols

Enable parallel computations Computation of session keys and authenticators is time

consuming. Can be done by the two parties in parallel rather

than sequentially. Hence, exchange the key material first.

Combine nonces and DH exponentials Use DH exponentials for key secrecy with PFS. Use nonces for

liveness and key freshness. This allows limited reuse of DH

exponentials, with "less-than-perfect" forward secrecy.

Compute MACK2B(B) and

AuthB = SIGB(nA| nB | gy | SAB)

Verify AUTHA, MACK2A(A).

Compute keys: PRF(gxy, nA|nB)

= K1A|K2A|K1B|K2B. Use them

to protect next messages.

Compute MACK2A(A) and

AUTHA = SIGA(nB| nA | gx | SAA)

Verify AUTHB, MACK2B(B). EK1B{B, AUTHB, MACK2B(B), CERTB}

A B

nA, gx, SAA(SPIA, cipher proposal)

EK1A{A, AUTHA, MACK2A(A), CERTA}

nB, gy, SAB(SPIB, cipher selection)

Example: AKE using DH with

authentication based on SIG (and MAC)

Add session ids, crypto negotiation, certificates, etc.

SAA, SAB are used to identify

the SA and negotiate ciphers

and traffic selectors.

Comp. keys: PRF(gxy, nA|nB)

= K1A|K2A|K1B|K2B. Use

them to protect messages.

IKEv1 Internet Key Exchange Version 1


IKEv1 key exchange

Phase 2 (Quick Mode): Establish children SA

Fast setup of one or more AH or ESP SA. Protected by IKE SA.

Also, SA re-keying.

Informational exchanges

Notification (error, status), SA termination. Protected by IKE SA.

Phase 1 (Main Mode): Establish an IKE SA Two "modes":

Main mode offers all features and needs 6 messages.

Aggressive modes uses only 3 messages, but less features

(e.g., no identity hiding).

Four authentication variants (you'll see only 3 of them):

Digital signatures (SIG).

Pre-Shared Key (PSK).

Public-key encryption (PKE, 2 variants!).


IKEv1 keys and authenticators

Generation of IKEv1 master shared secret SKEYID SIG authentication: SKEYID = PRF(Ni | Nr, gir).

PKE authentication: SKEYID = PRF(hash(Ni | Nr), CKYi | CKYr).

PSK authentication: SKEYID = PRF(PSK, Ni | Nr).

Nonces Ni, Nr, cookies CKYi, CKYr (IKE session IDs) for initiator, responder;

DH shared secret gir; pre-shared key PSK; PRF(k, x) = MACk(x), e.g., HMAC.

Generation of IKEv1 operational keys SK_d = PRF(SKEYID, gir | CKYi | CKYr | 0).

SK_a = PRF(SKEYID, SK_d | gir | CKYi | CKYr | 1).

SK_e = PRF(SKEYID, SK_a | gir | CKYi | CKYr | 2).

IKEv1 payloads are encrypted and authenticated using the keys SK_e

and SK_a, respectively (different keys for each direction).

SK_d is used as key seed to generate keys for ESP/AH SAs.

Computation of the IKEv1 authenticators HASHi = PRF(SKEYID, gi | gr | CKYi | CKYr | SAi | IDi).

HASHr = PRF(SKEYID, gr | gi | CKYr | CKYi | SAi | IDr).


Phase 1: Authentication using SIG

Initiator Responder

HDRi, gi, Ni

HDRr, gr, Nr

HDRi, SKi{IDi, [CERTi], SIGi(HASHi)}

Generate random

DH exponent i and

random nonce Ni

Compute the master secret SKEYID and the other IKE keys.

Payload of next IKE messages is encrypted and authenticated.

HDRr, SKr{IDr, [CERTr], SIGr(HASHr)}

Main mode

Exchange identities and authenticators. Identity hiding: Payload

is encrypted and authenticated using the IKE keys SK_e and SK_a.

HDRi(CKYi), SAi(cipher proposal)

HDRr(CKYr), SAr(cipher selection)

Anti-clogging is flawed in

all variants: exchange of

cookies is not stateless, so

partial DOS protection .

Negotiate ciphers, exchange cookies (session ids)

Exchange DH public exponentials and random nonces

The authenticators provide proof of identity and authenticate

data sent during IKE exchange (including cipher negotiation).

Generate random

DH exponent r and

random nonce Nr

Verify AUTHi.

Compute AUTHr.

AUTHr = SIGr(HASHr)

HASHr = PRF(SKEYID,

gr | gi | CKYr | CKYi |

SAi | IDr)

Compute AUTHi.

AUTHi = SIGi(HASHi)

HASHi = PRF(SKEYID,

gi | gr | CKYi | CKYr |

SAi | IDi)

Verify AUTHr.

Generate IKE keys

SKEYID = PRF(Ni|Nr, gir)

SKi = (SK_ei, SK_ai)

SKr = (SK_er, SK_ar)

Generate IKE keys

SKEYID = PRF(Ni|Nr, gir)



Aggressive

mode

Flawed: Identities could

have been encrypted. HDRi, [CERTi], SIGi(HASHi)

HDRi(CKYi), SAi, gi, Ni, IDi

HDRr(CKYr), SAr, gr, Nr, IDr, [CERTr], SIGr(HASHr)

Initiator Responder

No identity hiding.

Limited cipher negotiation

(initiator chooses DH gr.).

No anti-clogging.


Phase 1: Authentication using PSK

Initiator Responder

HDRi, gi, Ni

HDRr, gr, Nr

HDRi, SKi{IDi, [CERTi], HASHi}

Generate random

DH exponent i and

random nonce Ni

Both compute the master secret SKEYID and the other IKE keys.


HDRr, SKr{IDr, [CERTr], HASHr}

Main mode






Exchange DH public exponentials and random nonces



Generate random

DH exponent r and

random nonce Nr

Verify AUTHi.

Compute AUTHr.

AUTHr = HASHr

HASHr = PRF(SKEYID,

gr | gi |CKYr | CKYi |

SAi | IDr)

Compute AUTHi.

AUTHi = HASHi

HASHi = PRF(SKEYID,


SAi | IDi)

Verify AUTHr.

Generate IKE keys

SKEYID = PRF(S, Ni|Nr)



Generate IKE keys

SKEYID = PRF(S, Ni|Nr)



Pre-shared key S

Flawed: How does the

responder know what

PSK to use? Must use

IP address as identity.

Aggressive

mode

HDRi, HASHi

HDRi(CKYi), SAi, gi, Ni, IDi

HDRr(CKYr), SAr, gr, Nr, IDr, HASHr

Initiator Responder

Flawed: Identities could

have been encrypted.

No identity hiding.

Limited cipher negotiation

(initiator chooses DH gr.).

No anti-clogging.


Phase 1: Authentication using PKE (1)

Aggressive

mode

HDRi, HASHi

HDRi, SAi, gi, [hash(CERTr),] PKr{IDi}, PKr(Ni)

HDRr, SAr, gr, PKr{IDr}, PKi(Nr), HASHr

Initiator Responder

With identity hiding.

Limited cipher negotiation.

No anti-clogging.

Initiator Responder

HDRi, gi, [hash(CERTr),] PKr{IDi}, PKr(Ni)

HDRr, gr, PKr{IDr}, PKi(Nr)

HDRi, SKi{HASHi}

Generate random DH

exponent i and nonce Ni.

Encrypt with PKE Ni, IDi.



HDRr, SKr{HASHr}

Main mode






Exchange DH public exponentials and encrypted random nonces



Generate random DH

exponent r and nonce Nr.

Encrypt with PKE Nr, IDr.

Verify AUTHi.

Compute AUTHr

AUTHr = HASHr

HASHr = PRF(SKEYID,


SAi | IDr).

Compute AUTHi.

AUTHi = HASHi

HASHi = PRF(SKEYID,


SAi | IDi)

Verify AUTHr.

Generate IKE keys

SKEYID = PRF(hash(Ni |

Nr), CKYi | CKYr)



Generate IKE keys


Nr), CKYi | CKYr)



Weakness: Both parties

must know what public

encryption keys to use.

First variant

Weakness: Many

expensive PKE operations.


Phase 1: Authentication using PKE (2)

Aggressive

mode

HDRi, HASHi

HDRi, SAi, [hash(CERTr),] PKr(Ni), SKi{gi, IDi, [CERTi]}

HDRr, SAr, PKi(Nr), SKr{gr, IDr}, HASHr

Initiator Responder

With identity hiding.

Limited cipher negotiation.

No anti-clogging.

Initiator Responder

HDRi, [hash(CERTr),] PKr(Ni), SKi{gi, IDi, [CERTi]}

HDRr, PKi(Nr), SKr{gr, IDr}

HDRi, SKi{HASHi}

Generate random DH

exponent i and nonce Ni.

Encrypt with PKE Ni, IDi.

Generate SKi = PRF(Ni,

CKYi) = (SK_ei, SK_ai)



HDRr, SKr{HASHr}

Main mode






Exchange DH public exponentials and encrypted random nonces



Generate random DH

exponent r and nonce Nr.

Encrypt with PKE Nr, IDr.

Generate SKi = PRF(Ni,

CKYi) = (SK_ei, SK_ai).

Verify AUTHi.

Compute AUTHr.

AUTHr = HASHr

HASHr = PRF(SKEYID,


SAi | IDr).

Compute AUTHi.

AUTHi = HASHi

HASHi = PRF(SKEYID,


SAi | IDi)

Verify AUTHr.

Generate SKr = PRF(Nr,

CKYr) = (SK_er, SK_ar).


Nr), CKYi | CKYr)

Generate SKr = PRF(Nr,

CKYr) = (SK_er, SK_ar).


Nr), CKYi | CKYr)

Weakness: Initiator must

already have responder's

public encryption key.

Revised (optimized) variant

Advantage: Reduces the

number of PKE operations.


Phase 2 (Quick Mode)

Initiator Responder

HDRi, SKi{Hash(3)}

HDRi, SKi{Hash(1), SAi, Ni [, gi ][, IDci, IDcr]}

IKE SA (Phase 1 completed)

HDRr, SKr{Hash(2), SAr, Nr [, gr ] [, IDci, IDcr]}

Phase 2 is used to create a child SA (ESP or/and AH) of the

current IKE SA or for re-keying. New keys for this SA are

computed using a secret derived in Phase 1 for this purpose

(SKEYID_d), the new nonces and the (optional) D-H exponentials.

The messages are encrypted and integrity protected using the

algorithms and keys established in Phase 1 (i.e., using IKE SA).

Phase 2 authenticators (M-ID is the Message ID in HDR):

HASH(1) = PRF(SKEYID_a, M-ID | SAi | Ni [ | gi ] [ | IDci | IDcr])

HASH(2) = PRF(SKEYID_a, M-ID | Ni | SAr | Nr [ | KE ] [ | IDci | IDcr])

HASH(3) = PRF(SKEYID_a, 0 | M-ID | Ni | Nr)

SAi: SPIi, cipher

proposal and

traffic selectors

SAr: SPIr, cipher

selection and traffic

selectors

Key generation (AH/ESP protocol; new ciphers, nonces, DH secret):

No PFS: KEYMAT = PRF(SKEYID_d, protocol | SPI | Ni | Nr)

With PFS: KEYMAT = PRF(SKEYID_d, gir (new) | protocol | SPI | Ni | Nr)

IKEv2 Internet Key Exchange Version 2


IKEv2 overview

IKEv2 is a substantial redesign of IKE

Revised authentication methods

Keeps authentication using SIG or PSK. Skips PKE variant.

Adds extensible authentication using EAP.

Simpler and more efficient

Two handshakes (4 messages) are sufficient to set up an IKE

SA together with a child SA (the typical case).

Contrast this with 6 + 2 messages in IKEv1.

Clear description in one document

RFC 4306 (Dec. 2005).

Improved functionality

Elimination of IKEv1 flaws.

Some new features: e.g., support for NAT traversal.


IKEv2 exchanges: overview

Initiator Responder IKE_SA_INIT exchange - Negotiate cryptographic algorithms for IKE SA.

- Exchange nonces and Diffie-Hellman public exponentials.

IKE_SA_INIT request

IKE_SA_INIT response

IKE_AUTH exchange • Exchange identities and (optionally) certificates.

• Authenticate using signature or MAC (for PSK) and check

integrity of previous messages, prove knowledge of the

IKE SA keys (they are used to protect these messages).

• Establish the first AH or/and ESP child SA(s).

IKE_AUTH request

IKE_AUTH response

CREATE_CHILD_SA exchange (optional) • Establish additional child SA(s), or re-key IKE SA.

CREATE_CHILD_SA request

CREATE_CHILD_SA response

INFORMATIONAL exchanges • Error notifications, liveness tests, SA termination, etc.

• Request-response exchange, like all IKE exchanges.

Compute

IKE SA keys

Compute

IKE SA keys

Pro

tecte

d m

essag

e p

aylo

ad

(en

cry

pti

on

an

d M

AC

usin

g E

SP

fo

rmat)


IKE_SA_INIT exchange

Initiator Responder IKE_SA_INIT exchange - Negotiate cryptographic algorithms for IKE SA.

- Exchange nonces and Diffie-Hellman (DH) exponentials.

M1: IKE_SA_INIT request: HDR, SAi1, KEi, Ni.

I want to set up a new SA. Ciphers I propose for IKE SA, SAi1.

My DH public exponential KEi = gi, and my nonce Ni.

M2: IKE_SA_INIT response: HDR, SAr1, KEi, Nr.

Ciphers I choose for IKE SA, SAr1. My DH public exponential KEr = gr,

and my nonce Nr.

This completes the selection of cryptographic algorithms and the

exchange of key material. Both parties can now compute SKEYSEED and

generate the IKE keys, used starting with the next exchange, IKE_AUTH.

A clogging protection mechanism can be used in case of denial-of-service

attacks (responder replies with a cookie instead of the normal response).

An SA payload contains an ordered list of proposals. Each proposal may

contain multiple protocols (IKE, ESP, or AH). Each protocol may contain

multiple transforms. Each transform may contain multiple attributes.


Key generation for IKE_SA

Master shared secret SKEYSEED

SKEYSEED = PRF(Ni | Nr, gir).

Ni, Nr nonces (initiator, responder); gir = Diffie-Hellman shared secret.

Notation: PRF(k, x) = MACk(x), where MAC is HMAC or AES-XCBC.

Computation of IKEv2 keys

PRF+ (SKEYSEED, Ni | Nr | SPIi | SPIr) =

SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr

SK_d is used as key seed to similarly generate keys for children SAs.

MAC keys SK_ai/SK_ar and encryption keys SK_ei/SK_er for IKE

initiator/responder; SK_pi, SK_pr are used for (entity) authentication.

Iterated PRF for key expansion

PRF+ (K, S) = T1 | T2 | T3 | ...

T1 = PRF(K, S | 0x01); T2 = PRF(K, T1 | S | 0x02);

T3 = PRF(K, T2 | S | 0x03); T4 = PRF(K, T3 | S | 0x04), ...


IKE_AUTH exchange

IKE_AUTH exchange - Exchange identities and (optionally) certificates.

- Authenticate using signature or MAC (for PSK) and check

integrity of previous messages, prove knowledge of the

IKE SA keys (they are used to protect these messages).

- Establish the first AH or/and ESP child SA(s).

M3: IKE_AUTH request:

HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}.

My identity IDi. My certificates CERT, my trusted CAs CERTREQ, your

assumed identity IDr (optional). My signature on payloads of previous

messages AUTH. Ciphers I propose for the first child SA, SAi2, and its

traffic selectors TSi, TSr. All encrypted and integrity protected using

established keys SK (ESP-like payload), also proving I know the keys.

M4: IKE_AUTH response: HDR, SK{IDr, [CERT,] AUTH, SAr2, TSi, TSr}.

My identity IDr and my certificates CERT (optional). My signature on

payloads of previous messages AUTH. Ciphers I choose for the first

child SA, SAr2, and traffic selectors TSi, TSr. All this encrypted and

integrity protected using established keys SK (ESP-like payload).

This completes the creation of the IKE SA and of the first CHILD_SA (ESP

or/and AH). The keys for the first child SA are computed using the same

algorithm like the IKE keys, using SK_d as key seed and nonces Ni, Nr.

Initiator Responder

Pro

tecte

d m

essag

e p

aylo

ad

(en

cry

pti

on

an

d M

AC

usin

g E

SP

fo

rmat)


Authentication of IKE SA

Authentication data Initiator: Auth_data = M1 | Nr | PRF(SK_pi, IDi).

Responder: Auth_data = M2 | Ni | PRF(SK_pr, IDr).

Authentication based on signature AUTH = SIG(Auth_data).

This also provides data authentication for the IKE_SA_INIT

exchange (M1 and M2, including SA negotiation, etc.).

Moreover, IKE_AUTH is protected by MAC and encryption with

the new IKE SA keys. This also proves knowledge of the keys.

Authentication based on PSK MAC with shared key K instead of signature.

AUTH = PRF(PRF(K, "Key Pad for IKEv2"), Auth_data).

Extensible authentication Modified authentication exchange to accommodate the

Extensible Authentication Protocol (EAP).


CREATE_CHILD_SA exchange

CREATE_CHILD_SA exchange

- Establish additional child SA(s) for an existing IKE SA.

- Or re-key the current IKE SA.

CREATE_CHILD_SA request: HDR, SK{[N], SA, Ni, [KEi], [TSi, TSr]}.

I want to set up an additional child SA. Proposed ciphers, SA (and

optionally traffic selectors TSi, TSr). My new nonce Ni and optionally

a new DH public exponential KEi. Payload N indicates re-keying of

existing SA. All this encrypted and integrity-protected using the keys

SK of the current IKE SA (ESP-like payload).

CREATE_CHILD_SA response: HDR, SK{SA, Nr, [KEr], [TSi, TSr]}.

OK. Ciphers I choose, SA (and optionally traffic selectors TSi, TSr).

My new nonce Nr and optionally a new DH public exponential KEr.

All this encrypted and integrity-protected using the keys SK of the

current IKE SA (ESP-like payload).

ESP SAs and AH SAs exist in pairs, one for each direction. A CHILD_SA

exchange can create a pair of ESP SAs, AH SAs, or ESP+AH SAs.

Keys for these SAs are computed using SK_d and the new nonces and (if

exchanged) DH exponentials (next slide).

Initiator Responder

Pro

tecte

d m

essag

e p

aylo

ad

(en

cry

pti

on

an

d M

AC

usin

g E

SP

fo

rmat)


Keys for CHILD_SAs. Re-keying

Creating CHILD_SAs and re-keying existing SAs

A first CHILD_SA is created by the IKE_AUTH exchange.

CREATE_CHILD_SA exchanges are used to create additional

CHILD_SAs or to re-key the IKE SA and existing CHILD_SAs.

IKE SA re-keying

SKEYSEED = PRF(SK_d (old), [gir (new) | ] Ni | Nr).

Ni, Nr, and DH secret (if available) from CREATE_CHILD_SA.

SK_d, SK_ai, SK_ar, SK_ei, and SK_er are then computed

from SKEYSEED as described earlier.

Key material for CHILD_SAs

KEYMAT = PRF+(SK_d, [gir (new) | ] Ni | Nr).

First CHILD_SA: No DH secret. Ni, Nr from IKE_SA_INIT exchange.

Next CHILD_SAs: Ni, Nr, and (optionally) the DH secret (if available) from

CREATE_CHILD_SA exchange.

Encrypt and MAC keys are taken from KEYMAT (similar to IKE).

Documents

IPsec and Secure VPNsdiscipline.elcom.pub.ro/cscn/project/CSCN_intro-to-ipsec.pdf · Cryptography and Security in Communication Networks IPsec and Secure VPNs (self study for project)