Transcript Lecture 05 - MyCourses

Network Security:
IPsec
Tuomas Aura
T-110.5241 Network security
Aalto University, Autumn 2015
IPsec:
Architecture and protocols
2
Internet protocol security (IPsec)
Network-layer security protocol
Protects IP packets between two hosts or gateways
Transparent to transport layer and applications:
security policy is defined and enforced on network level
IP addresses used to as host identifiers
Two steps:
1. IKE authenticated key exchange creates security associations
2. ESP session protocol protects data
Specified by Internet Engineering Task Force (IETF)
Original goal: encryption and authentication layer that will
replace all others and meet all Internet security needs
Security (IPsec) was a sales point for IPv6, but IPsec now works
also for IPv4
3
IPsec architecture [RFC4301]
Node A
PAD
Session
Key
IKE(v2)
SPD
Security
Policy
Database
IPsec
SAD
Security
Association
Database
Untrusted
network
1. Key exchange
Node B
PAD
Session
Key
IKE(v2)
IKE SA
SPD
IPsec SA Pair
Security
Policy
Database
2. ESP
protects data
IPsec
Security
Association SAD
Database
Security associations (SA) created by IKE, used by IPsec ESP
Security policy guides SA creation and selection for use
IPsec is part of the IP layer in the OS kernel; IKE is a user-space
service (daemon)
4
Internet Key Exchange (IKEv2)
Initial exchanges (using the notation from the IPsec RFC):
1.
2.
3.
4.
I → R:
R → I:
I → R:
R → I:
HDR(A,0), SAi1, KEi, Ni
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
HDR(A,B), SK { IDi, [CERT,] [CERTREQ,] [IDr,] AUTHi, SAi2, TSi, TSr }
HDR(A,B), SK { IDr, [CERT,] AUTHr, SAr2, TSi, TSr }
A, B = SPI values that identity the protocol run and the created IKE SA
Nx = nonces
SAx1 = offered and chosen algorithms, DH group (p and g)
KEx = Diffie-Hellman public key (gx or gy)
CERTREQ = accepted root CAs (or other trust roots)
IDx, CERT = identity, certificate
AUTHi = SignI (Message 1, Nr, h(SK, IDi))
AUTHr = SignR (Message 2, Ni, h(SK, IDr))
SK = h(Ni, Nr, gxy) — actually, 6 different keys are derived from this
SK { … } = ESK( …, MACSK(…)) — MAC and encrypt with session key
SAx2, TSx = parameters for the first IPsec SA (algorithms, SPIs, traffic selectors)
Internet Key Exchange (IKEv2)
Initial exchanges:
1.
2.
3.
4.
I → R:
R → I:
I → R:
R → I:
HDR(A,0), SAi1, KEi, Ni
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
HDR(A,B), SK { IDi, [CERT,] [CERTREQ,] [IDr,] AUTHi, SAi2, TSi, TSr }
HDR(A,B), SK { IDr, [CERT,] AUTHr, SAr2, TSi, TSr }
A, B = SPI values that identity the protocol run and the created IKE SA
Nx = nonces
SAx1 = offered and chosen algorithms, DH groupSecret,
(p andfresh
g) session key?
KEx = Diffie-Hellman public key (gx or gy)
Mutual authentication?
CERTREQ = accepted root CAs (or other trust roots)
Entity authentication and
IDx, CERT = identity, certificate
key confirmation?
AUTHi = SignI (Message 1, Nr, h(SK, IDi))
Contributory?
AUTHr = SignR (Message 2, Ni, h(SK, IDr))
Perfect forward secrecy?
SK = h(Ni, Nr, gxy) — actually, 6 different keys areIntegrity
derivedcheck
from this
for initial negotiation?
SK { … } = ESK( …, MACSK(…)) — MAC and encryptNon-repudiation
with session keyor plausible deniability?
SAx2, TSx = parameters for the first IPsec SA (algorithms,
SPIs, traffic selectors)
Identity protection?
IKEv2 with a cookie exchange
In the second message, responder may send a cookie (a nonce)
Goal: prevent DoS attacks from a spoofed IP address
1.
2.
3.
4.
5.
I → R:
R → I:
I → R:
R → I:
I → R:
6.
R → I:
HDR(A,0), SAi1, KEi, Ni
HDR(A,0), N(COOKIE)
// R stores no state
HDR(A,0), N(COOKIE), SAi1, KEi, Ni
HDR(A,B), SAr1, KEr, Nr, [CERTREQ] // R creates a state
HDR(A,B), SK{ IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr }
HDR(A,B), ESK (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
Security Associations (SA)
One IKE SA for each pair of nodes
Stores the master key SK = h(Ni, Nr, gxy) for creating IPsec SAs
At least one IPsec SA pair for each pair of nodes
Stores the negotiated session protocol, encryption and
authentication algorithms, keys and other session parameters
Stores the encryption algorithm state
IPsec SAs always come in pairs, one in each direction
IPsec SAs are identified by a 32-bit security parameter
index (SPI) [RFC4301]
The destination node selects the SPI value
Node stores IPsec SAs in a security association database
(SAD)
10
Session protocol
 Encapsulated Security Payload (ESP) [RFC 4303]
 Encryption and/or MAC for each packet
 Optional replay prevention with sequence numbers
 Protects the IP payload (= transport-layer PDU) only
 ESP with encryption only is insecure but allowed by
some implementations!

Old protocol: Authentication Header (AH)




Do not use for new applications
Authentication only, no encryption
Protects payload and some IP header fields
Exists because of American export controls in the 90s
11
Session protocol modes
Transport mode
Encryption and/or authentication from end host to end host
Network
Encrypted
Tunnel mode
Encryption and/or authentication between two gateways (VPN)
IPsec gateway
Internet
IPsec gateway
!
Intranet
Intranet
Encrypted
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 connection)
Untrusted
access
network
Internet
IPsec
gateway
!
Intranet
14
ESP packet format
Original packet:
IP header
ESP header and trailer =
SPI + Sequence number + Padding
ESP authentication trailer =
message authentication code (MAC)
IP Payload
ESP in transport mode:
Original
IP header
Original
ESP header IP Payload
ESP trailer Auth trailer
Encrypted
Authenticated
ESP in tunnel mode:
IP header
Original
ESP header IP header
IP Payload
!
ESP trailer Auth trailer
Encrypted
Authenticated
16
IPsec databases
Security association database (SAD)
Contains the IPsec SAs i.e.t the dynamic protection state
Security policy database (SPD)
Contains the static security policy
Usually set by system administrators (e.g. Windows group policy),
although some protocols and applications make dynamic changes
Peer authorization database (PAD)
Needed in IKE for mapping between authenticated names and IP
addresses
Conceptual; not implemented as an actual database
Additionally, the IKE service/daemon stores IKE SAs:
Master secret created with Diffie-Hellman key exchange
Used for instantiating new IPsec SAs
(Note: our description of SPD differs somewhat from RFC4301 and is probably closer to
most implementations)
18
Gateway SPD/SAD example
SPD of gateway A, interface 2
Protocol
Local IP
Port
Remote IP
Port
Action
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
*
*
*
*
*
BYPASS
Protect VPN traffic
All other peers
Pointers to created associations
SAD of
gateway A
SPI
SPD selector
values
Protocol
Algorithms, keys,
algorithm state
spi1
TCP, 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
interface1
1.2.3.1
interface2
2.3.4.5
IPsec gateway A
interface1
4.5.6.7
interface2
5.6.7.1
IPsec gateway B
19
Security policy database (SPD)
Specifies the static security policy
Policy maps inbound and outbound packets to actions
SPD = linearly ordered list of policies
Policy = selectors + action
The first 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 destination ports
Actions: BYPASS (allow), DISCARD (block), or PROTECT
PROTECT specifies also the session protocol and algorithms
Packet is mapped to a suitable IPsec security association (SA)
If the SA does not exist, IKE is triggered to create them
SPD stores pointers to previously created SAs
Multi-homed nodes have a separate SPD for each network interface
(in practice, they can be stored in one database)
(multihomed = node with multiple network interfaces)
Policies at peer nodes must match if they are to communicate
20
Some problems with IPsec
IPsec and NAT
Problems:
NAT cannot multiplex IPsec: impossible to modify SPI or
port number because they are authenticated
→ Host behind a NAT could not use IPsec
NAT traversal (NAT-T):
UDP-encapsulated ESP (UDP port 4500)
NAT detection: extension of IKEv1 and IKEv2 for sending
the original source address in initial packets
→ Enables host behind a NAT to use IPsec
27
IPsec and mobility
Problem:
IPsec policies and SAs are bound to IP addresses. Mobile
nodes change their IP address
Mobile IPv6:
Home address (HoA) in Mobile IP v6 is stable. But Mobile IPv6
itself depends on IPsec for the tunnel between HA and MN. →
chicken-and-egg situation
Solutions:
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 solutions
Proposed MOBIKE and HIP mobility protocols intergrate IPsec
and mobility
28
IPsec and name resolution
PC-A
Application
OS
1. Name
resolution
IPsec
Policy:
1.2.*.* ESP
*
BYPASS
Response: “1.2.3.4”
Query: “server-b”
IP Network
3. IPsec Protection
Application Data
Server-B
1.2.3.4
2. Key Exchange (IKE)
Name
service
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)
30
Classic IPsec/DNS Vulnerability
Honest host
Application
OS
1. Name
resolution
IPsec
Policy
3. IPsec Protection
Application Data
Attacker
pc-c.example.org
3.4.5.6
2. Key Exchange (IKE)
1.2.*.* ESP
*
BYPASS
Spoofed Response: “3.4.5.6”
Query: “server-b.example.org”
IPsec policy selection depends on secure name resolution
Attacker spoofs DNS response to circumvent the IPsec policy
31
IPsec and Certificates
Honest host
“server-b. Application
example.org”
“1.2.3.4”
Connect(“1.2.3.4”)
2. Key Exchange (IKE)
OS
1. Name
resolution
“1.2.3.4” =
“server-b” ?
Certificate:
{“server-b.example.org”,
PublicKeyC}CA
Query:
Response:
“server-b.
“1.2.3.4”
example.org”
Name service
Let’s assume DNS is secure
Another problem: IKE knows the peer IP address, not the peer name;
the certificate only contains the name
 How does IPsec decide whether the certificate is ok?
32
PC-A
Application
OS
1. Name
resolution
IPsec
Policy:
*
ESP
Response: “1.2.3.4”
Query: “server-b”
3. IPsec Protection
Application Data
Server-B
1.2.3.4
2. Key Exchange (IKE)
Certificate:
{“server-b”, PublicKeyB}CA
Name
service
What can go wrong?
33
IPsec and Certificates - Attack
PC-A
Application
OS
1. Name
resolution
IPsec
Policy:
*
ESP
Response: “1.2.3.4”
Query: “server-b”
3. IPsec Protection
Application Data
Attacker
PC-C
(using
1.2.3.4)
2. Key Exchange (IKE)
Certificate:
{“pc-c”, PublicKeyC}CA
Name
service
IPsec cannot detect whether the certificate contains the correct name
Secure DNS (forward lookup) does not help — why?
Result: group authentication of those certified by the same CA
→ maybe ok for protecting an intranet where the goal is to keep outsiders out
34
Peer authorization database (PAD)
IPsec specification [RFC4301] defines a database that
maps authenticated names to the IP addresses which
they are allowed to represent
How implemented? Secure reverse DNS would be the best
solution — but it does not exist
Other solutions:
Secure DNS — both secure forward and reverse lookup needed,
which is unrealistic
Give up IPsec transparency — extend the socket API so that
applications can query for the authenticated name and other
security state information
Connect by name — change the socket API so that the
connect() call specifies the host name, not the IP address
Currents situation: IPsec is only used for VPN where the
gateway names and IP addresses are preconfigured
35
Related reading
William Stallings. Network security essentials:
applications and standards, 3rd ed. chapter 6; 4th
ed. chapters 8, 11; 5th ed. chapter 9
William Stallings. Cryptography and Network
Security, 4th ed. chapter 16; 6th ed. chapter 20
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
36
Exercises
Why is IPsec used mainly for VPN implementations? Does IPsec VPN suffer from any
of the problems mentioned in the lecture, or can they be avoided?
For the IPsec policy examples of this lecture, define the IPsec policy for the peer
nodes i.e. the other ends of the connections.
Try to configure the IPsec policy between two computers. What difficulties did you
meet? Use ping and TCP to test connectivity. Use a network sniffer to observe the key
exchange and to check that packets on the wire are encrypted.
What administrative problems arise from the fact that IPsec security policies in two
communicating 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 decorrelation. Why?)
Each SAD entry stores (caches) policy selector values from the policy that was used
when creating 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)?
Would policy decorrelation simplify the situation?
37