Transcript IKE - Internet Key Exchange

Internet Key
Exchange
IPSec – Reminder
SAD
SPI
1
SA
2
SA
3
SA
…
…
IPSec – Reminder
SA
• Security Association Database (SAD) holds
SA’s
• Security Associations (SA) is a one way,
cryptographically protected connection
between a sender and a receiver that affords
security services to traffic
Alice
spi
SA’s
spi
1
1
2
2
…
13
…
21
Bob
SA’s
Bob to Alice
Alice’s spi: 21
…
Alice to Bob
Bob’s spi: 17
Bob to Alice
Bob’s spi: 2
…
17
Alice to Bob
Alice’s spi: 13
IPSec – Reminder
SA
SA contains the fields:
• protocol identifier (ESP or AH)
• mode (tunnel or transport)
• algorithms for encryption/ decryption/
authentication and their respective keys
• lifetime
• SPI’s
• sequence number
IPSec – Reminder
Where does IKE fit in?
SA’s building and managing is either:
• Static (manual) – keys and other attributes
of SA are manually configured by system
administrator. Practical for small, relatively
static environments.
• Dynamic (automated) – On-demand
creation of keys. Handled by IKE protocol
IKE
• IKE is a protocol that builds and manages IPSec
SA’s between two computers that implement
IPSec.
• IKE is the only standard protocol for building
IPSec SA’s (Standard IPSec implementation must
also implement IKE)
• IKE (like IPSec) is carried out either between a
pair of hosts, a pair of security gateways or a host
and a security gateway
IKE
• IKE is a protocol that builds and manages IPSec
SA’s between two computers that implement
IPSec.
• IKE is the only standard protocol for building
IPSec SA’s (Standard IPSec implementation must
also implement IKE)
• IKE (like IPSec) is carried out either between a
pair of hosts, a pair of security gateways or a host
and a security gateway
Endpoint to Endpoint Transport
• Both endpoints of the IP connection implement
IPsec
• Used with no inner IP header
• One of the protected points can be behind a
NAT node
Protected
Endpoint
IPsec Tunnel
Protected
Endpoint
Gateway to Gateway Tunnel
• Neither point of the IP connection implements IPsec,
but network nodes between them protect traffic for
part of the way
• Protection is transparent to the endpoints
• The inner IP header contains the IP addresses of the
actual endpoints
Protected
Subnet
gateway
IPsec
Tunnel
Protected
gateway
Subnet
Endpoint to Gateway Transport
• A protected endpoint (typically a portable roaming
computer) connects back to its corporate network
through an IPsec protected tunnel
• The protected endpoint will want an IP address
associated with the gateway so that packets returned to
it will go to the gateway and be tunneled back
• The protected endpoint may be behind a NAT
Protected
Protected
Endpoint
Subnet
IPsec Tunnel
gateway
and/or
Internet
expectations from IKE
•
•
•
•
•
•
•
•
•
Secrecy and authenticity
Protection against replay attacks
Scalability (being suitable for big networks)
Privacy and anonymity (protecting identity of
players in the protocol)
Protection against DOS
Efficiency (both computational and minimal in the
number of messages)
Independence of cryptographic algorithms
Minimize protocol complexity
Reliability
Key Exchange Protocols
• Key exchange protocols goal is to agree on
a shared key for the two participant
• Should implement
- authenticity
- secrecy
Long and Short Term Keys
•
To support authenticity parties should
know a mutual secret key. This key is
called long term key.
• The keys negotiated in the protocol are
called short term keys.
• There are two types of long term keys:
1. Pre-shared secret
2. Public/private keys
Long and Short Term Keys
Why the need for short term keys?
• It is not advisable to encrypt a lot of data with the
same key
• It is advisable to separate between encryption keys
and authentication keys
Why not sending the new key encrypted using the
long term key?
• PFS
PFS
Perfect Forward Secrecy
• Exposure of long term keys will not entail
exposure of short term keys that are created
in the current execution of the protocol
• PFS is optionally provided in IKE (detailed
later)
IKE version 1
• IKE version 1 is a hybrid of three protocols
(actually a framework and two protocols)
• Version 1 grew out of ISAKMP framework
and OAKLEY and SKEME protocols that
work within that framework.
ISAKMP (IKE version 1)
• Stands for “Internet Security Association
and Key Management” Protocol
• Created by NSA (National Security Agency)
• Framework (not really a protocol) for
authentication and key exchange.
• This framework decides on the SA’s
attributes the parties will use.
ISAKMP (IKE version 1)
• Designed to be key exchange independent
(supports many different key exchanges)
• In IKE version 1 ISAKMP uses part of
OAKLEY and part of SKEME.
SKEME (IKE version 1)
• Describes a versatile key exchange
technique
Provides:
• anonymity
• repudiability
• quick key refreshment
OAKLEY (IKE version 1)
• Describes a series of key exchanges and
details the services provided by each
• Based on Diffie-Hellman algorithm but
providing added security
• Generic in that it does not dictate specific
formats
OAKLEY (IKE version 1)
Characterized by five important features:
1. Cookies to prevent clogging attacks
2. Negotiation of a group (specifying global
parameters of DH)
3. Use of nonces to ensure against replay
attacks
4. Exchange of public key values
5. Authentication of DH to prevent man-inthe-middle attacks
Diffie-Hellman Groups
• A group for the DH key exchange specifies
the global parameters of DH.
• Each group includes the definition of 2
global parameters and the identity of the
algorithm
• Three of these groups are classic DH
algorithm using modular exponentiation
Diffie-Hellman – groups id=1,2,5
All these three groups (id=1,2,5) have:
• Generator = 2
For group id=1:
• Prime = 2^768 - 2^704 – 1 + 2^64 * { [2^638 pi]
+ 149686}
For group id=2:
• Prime = 2^1024 - 2^960 – 1 + 2^64 * { [2^894 pi]
+ 129093}
For group id=5:
• Prime = 2^1536 - 2^1472 – 1 + 2^64 * { [2^1406
pi] + 741804}
Diffie-Hellman – groups id=3,4
• Over galois fields using elliptic curves.
IKE Version 2
From this point on we focus on IKE version 2
• IKE version 2 is a single protocol rather
than three that cross reference one another
and is described in a single self-contained
document
Main benefits of IKE Version 2
over Version 1
IKEv2 preserves most of the features of IKEv1. The
idea behind IKEv2 was to make it as easy as
possible for IKEv1 implementations to be
modified for IKEv2.
• Later we will see that IKE is a two-phase protocol.
Version 2 greatly simplified IKE by replacing the
8 possible phase 1 exchanges with a single
exchange.
• This single exchange provides identity hiding in 2
round trips rather than 3 in version 1
Main benefits of IKE Version 2
over Version 1
• Version 2 decreased latency by allowing
setup of SA to be piggybacked on the initial
exchange
• Version 2 increased security by allowing
responder to be stateless until initiator can
receive at claimed IP address
Side benefits of IKE Version 2
over Version 1
• cryptographic syntax replaced with one
simplified syntax
• a few fields were removed (ex: DOI, SIT)
• possible error states reduced
Details and variations
• IKE normally listens on UDP port 500,
though may also be received on port 4500
with a slightly different format
Reliability
IKE is a reliable protocol.
• Initiator responsible for retransmission in the
event of timeout, therefore must remember each
request until it receives the corresponding
response
• Responder retransmits a response only when it
receives retransmission , therefore must remember
each response until it receives a request with a
larger sequence number plus window size
• On failure all states associated with SA are
discarded
Reliability
• IKE definition includes recovery from
transmission error: packet loss, packet
replay, packet forgery
Functionality
• IKE is designed to function so long as:
1. at least one of a series of retransmitted packets
reaches its destination before timing out
2. channel not full of forged or replayed packets
(exhausting network or CPU)
• Even if these two minimum requirements are
absent, IKE fails cleanly as though the network
was broken
NAT Traversal
• IPsec through a NAT introduces problems.
• protocols which include IP addresses of endpoint
within the payload (like IPSec) necessitate that
NAT understands the protocol and modify the
internal references and those in the headers
• In transport mode changing IP address will cause
checksums to fail. In tunnel mode there are
routing problems.
NAT Traversal
• For that reason, IKE supports UDP
encoding that is easier for NATs to process
• It is less efficient but is easier for NAT to
process
• This is where port 4500 comes in. When
working through a NAT it is better to pass
IKE packets over port 4500 which runs the
NAT-friendly protocol.
To Sum Up Overview
We talked about:
• IPSec SAs
• what roles IKE play
• Design issues
• Key exchange protocols: long/short terms keys, pfs
• version 1: structure and features
• version 2
• Reliability
• Terms of functionality
• NAT friendly protocol