ipsec and secure vpnsdiscipline.elcom.pub.ro/cscn/project/cscn_intro-to-ipsec.pdf · cryptography...
TRANSCRIPT
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
© Octavian Catrina 3
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
© Octavian Catrina 5
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
© Octavian Catrina 6
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.
© Octavian Catrina 7
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
© Octavian Catrina 10
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.
© Octavian Catrina 11
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.
© Octavian Catrina 12
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.
© Octavian Catrina 13
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.
© Octavian Catrina 14
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)
© Octavian Catrina 15
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.
© Octavian Catrina 16
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
© Octavian Catrina 17
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.
© Octavian Catrina 18
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).
© Octavian Catrina 19
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
© Octavian Catrina 20
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).
© Octavian Catrina 21
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.
© Octavian Catrina 22
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
© Octavian Catrina 23
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
© Octavian Catrina 24
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
© Octavian Catrina 26
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.
© Octavian Catrina 27
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.
© Octavian Catrina 28
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.
© Octavian Catrina 29
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
© Octavian Catrina 30
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))
© Octavian Catrina 31
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
© Octavian Catrina 32
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
© Octavian Catrina 34
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!).
© Octavian Catrina 35
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).
© Octavian Catrina 36
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)
SKi = (SK_ei, SK_ai)
SKr = (SK_er, SK_ar)
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.
© Octavian Catrina 37
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.
Payload of next IKE messages is encrypted and authenticated.
HDRr, SKr{IDr, [CERTr], 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)
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 = HASHr
HASHr = PRF(SKEYID,
gr | gi |CKYr | CKYi |
SAi | IDr)
Compute AUTHi.
AUTHi = HASHi
HASHi = PRF(SKEYID,
gi | gr | CKYi | CKYr |
SAi | IDi)
Verify AUTHr.
Generate IKE keys
SKEYID = PRF(S, Ni|Nr)
SKi = (SK_ei, SK_ai)
SKr = (SK_er, SK_ar)
Generate IKE keys
SKEYID = PRF(S, Ni|Nr)
SKi = (SK_ei, SK_ai)
SKr = (SK_er, SK_ar)
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.
© Octavian Catrina 38
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.
Both compute the master secret SKEYID and the other IKE keys.
Payload of next IKE messages is encrypted and authenticated.
HDRr, SKr{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)
Negotiate ciphers, exchange cookies (session ids)
Exchange DH public exponentials and encrypted random nonces
The authenticators provide proof of identity and authenticate
data sent during IKE exchange (including cipher negotiation).
Generate random DH
exponent r and nonce Nr.
Encrypt with PKE Nr, IDr.
Verify AUTHi.
Compute AUTHr
AUTHr = HASHr
HASHr = PRF(SKEYID,
gr | gi | CKYr | CKYi |
SAi | IDr).
Compute AUTHi.
AUTHi = HASHi
HASHi = PRF(SKEYID,
gi | gr | CKYi | CKYr |
SAi | IDi)
Verify AUTHr.
Generate IKE keys
SKEYID = PRF(hash(Ni |
Nr), CKYi | CKYr)
SKi = (SK_ei, SK_ai)
SKr = (SK_er, SK_ar)
Generate IKE keys
SKEYID = PRF(hash(Ni |
Nr), CKYi | CKYr)
SKi = (SK_ei, SK_ai)
SKr = (SK_er, SK_ar)
Weakness: Both parties
must know what public
encryption keys to use.
First variant
Weakness: Many
expensive PKE operations.
© Octavian Catrina 39
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)
Both compute the master secret SKEYID and the other IKE keys.
Payload of next IKE messages is encrypted and authenticated.
HDRr, SKr{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)
Negotiate ciphers, exchange cookies (session ids)
Exchange DH public exponentials and encrypted random nonces
The authenticators provide proof of identity and authenticate
data sent during IKE exchange (including cipher negotiation).
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,
gr | gi | CKYr | CKYi |
SAi | IDr).
Compute AUTHi.
AUTHi = HASHi
HASHi = PRF(SKEYID,
gi | gr | CKYi | CKYr |
SAi | IDi)
Verify AUTHr.
Generate SKr = PRF(Nr,
CKYr) = (SK_er, SK_ar).
SKEYID = PRF(hash(Ni |
Nr), CKYi | CKYr)
Generate SKr = PRF(Nr,
CKYr) = (SK_er, SK_ar).
SKEYID = PRF(hash(Ni |
Nr), CKYi | CKYr)
Weakness: Initiator must
already have responder's
public encryption key.
Revised (optimized) variant
Advantage: Reduces the
number of PKE operations.
© Octavian Catrina 40
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
© Octavian Catrina 42
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.
© Octavian Catrina 43
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)
© Octavian Catrina 44
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.
© Octavian Catrina 45
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), ...
© Octavian Catrina 46
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)
© Octavian Catrina 47
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).
© Octavian Catrina 48
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)
© Octavian Catrina 49
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).