Upload
sandrobigbos
View
217
Download
0
Embed Size (px)
Citation preview
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 1/31
1
© From Computer Networking, by Kurose&Ross5: Securing IP 5-1
Managing and SecuringComputer Networks
Guy Leduc
Chapter 5:Network Layer Security
For a summary, see:
Computer Networking: A Top Down Approach ,
6th edition.Jim Kurose, Keith RossAddison-Wesley, March 2012.(section 8.7)
Mainly based on
Network Security - PRIVATE Communication in a PUBLIC World C. Kaufman, R. Pearlman, M. Speciner Pearson Education, 2002.(chapters 17 and 18)
© From Computer Networking, by Kurose&Ross5: Securing IP 5-2
Chapter 5: Network LayerSecurity
Chapter goals:
! security in practice:" Security in the network layer (versus other layers)
" IPsec
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 2/31
2
© From Computer Networking, by Kurose&Ross5: Securing IP 5-3
Chapter Roadmap
! Security in the network layer
! IPsec - The big picture
! IPsec protocols: AH and ESP
! IPsec Key Exchange protocol: IKE
© From Computer Networking, by Kurose&Ross5: Securing IP 5-4
Relative Location of SecurityFacilities in the TCP/IP Stack
! Both are general-purpose (i.e. application independent) solutions, but! IPsec is NOT specific to TCP
" Does work with UDP, and any other protocol above IP (e.g., ICMP, OSPF)
! IPsec protects the whole IP payload, including transport headers (e.g. port #)" Traffic analysis is thus more difficult (could be web, email, …)
! IPsec is from network entity to network entity, not from application processto application process" “Blanket coverage”
HTTP FTP SMTP
TCP / UDP
IP / IPsec
HTTP FTP SMTP
SSL / TLS
TCP
IP
Security at network levelSecurity at transport level
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 3/31
3
© From Computer Networking, by Kurose&Ross5: Securing IP 5-5
Virtual Private Networks (VPNs)! Institutions often want private networks for
security" Costly! Separate routers, links, DNS infrastructure
! VPN: institution’s inter-office traffic is sentover public Internet instead" Encrypted before entering public Internet"
Logically separate from other traffic
© From Computer Networking, by Kurose&Ross5: Securing IP 5-6
I P h e a d e r
I P s e c h e a d e r
S e c u r e p a y l o a d
I P
h e a d
e r
I P s e c
h e a d
e r
S e c u r e
p a y l o
a d I P
h e a d e r
I P s e c
h e a d e r
S e c u r e
p a y l o
a d
I P
h e a d e r
p a y l o
a d I P h
e a d e r
p a y l o
a d
headquartersbranch office
salesperson
in hotel
laptop
w/ IPsec
router w/
IPv4 and IPsec
router w/
IPv4 and IPsec
public
Internet
Virtual Private Networks (VPNs)
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 4/31
4
© From Computer Networking, by Kurose&Ross5: Securing IP 5-7
Three functional areas
! IP-level security encompasses the following3 functional areas:" origin authentication (and data integrity)
• assures that a received packet was, in fact,transmitted by the party identified as the source inthe packet header
• includes replay attack prevention• also assures that the packet has not been altered
" confidentiality• enables communicating nodes to encrypt messages to
prevent eavesdropping by third parties
" key management• secure exchange of keys
© From Computer Networking, by Kurose&Ross5: Securing IP 5-8
IP Security Overview! In 1994, the Internet Architecture Board (IAB) issued a
report entitled "Security in the Internet Architecture"" General consensus that the Internet needs more and better
security" In 1997, 2500 reported security incidents affecting nearly
150,000 sites" Most serious attacks: IP spoofing and packet sniffing" This justified the 2 main functions of IPsec
! The security capabilities were designed for IPv6 butfortunately they were also designed to be usable with thecurrent IPv4
! IPsec can encrypt and/or authenticate all traffic at the IPlevel. Thus IPsec provides the capability to securecommunications across a LAN, across private and publicWANs, and across the Internet" VPN (Virtual Private Networks)" Secure remote access over the Internet" Enhancing Extranet and Intranet connectivity with partners" Enhancing Electronic Commerce
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 5/31
5
© From Computer Networking, by Kurose&Ross5: Securing IP 5-9
Benefits of IPsec! When IPsec is implemented in a firewall or router, itprovides strong security that can be applied to alltraffic crossing the perimeter
! IPsec is below the transport layer and so is transparentto applications" No need to change software on a user or server system when
IPsec is implemented in a firewall or router" No need to train users, issue keying material on a per-user basis,
or revoke keying material when users leave the organization
! IPsec can provide security to individual users if needed! IPsec can play a vital role in the routing architecture. It
can ensure that:" router and neighbour advertisements come from authorized
routers" a redirect message comes from the router to which the initial
packet was sent" a routing update is not forged
© From Computer Networking, by Kurose&Ross5: Securing IP 5-10
Chapter Roadmap
! Security in the network layer
! IPsec - The big picture
! IPsec protocols: AH and ESP
! IPsec Key Exchange protocol: IKE
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 6/31
6
© From Computer Networking, by Kurose&Ross5: Securing IP 5-11
IPsec Transport Mode
!
IPsec datagram emitted and received byend-system
! Protects upper level protocols
IPsec IPsec
© From Computer Networking, by Kurose&Ross5: Securing IP 5-12
IPsec – tunneling mode (1)
! End routers are IPsec aware
! Hosts need not be
IPsec IPsec
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 7/31
7
© From Computer Networking, by Kurose&Ross5: Securing IP 5-13
IPsec – tunneling mode (2)
! Also tunneling mode
IPsecIPsec
© From Computer Networking, by Kurose&Ross5: Securing IP 5-14
Two Ipsec protocols
! Authentication Header (AH) protocol" provides source authentication & data integrity
but not confidentiality
! Encapsulation Security Protocol (ESP)" provides source authentication, data integrity,
and confidentiality
" more widely used than AH
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 8/31
8
© From Computer Networking, by Kurose&Ross5: Securing IP 5-15
Four combinations are possible!
Host modewith AH
Host modewith ESP
Tunnel modewith AH
Tunnel modewith ESP
Most common andmost important
© From Computer Networking, by Kurose&Ross5: Securing IP 5-16
IP Security Overview
!IPsec enables a system to"select security protocols,"determine the algorithm(s) to use, and"put in place any cryptographic keys required
!IPsec services and their support by AH and ESP
AH ESP ESP encryption only encryption+authentication
Access Control x x xConnectionless integrity x xData origin authentication x xRejection of replayed packets x x xConfidentiality x xLimited traffic flow confidentiality x x
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 9/31
9
© From Computer Networking, by Kurose&Ross5: Securing IP 5-17
Security associations (SAs)! Before sending data, a virtual connection is
established from sending entity to receivingentity
! Called “security association (SA)”" SAs are simplex: for only one direction
! Both sending and receiving entities maintainstate information about the SA" Recall that TCP endpoints also maintain state
information" IP is connectionless; IPsec is connection-oriented!
! How many SAs in VPN w/ headquarters, branchoffice, and n traveling salespeople?
© From Computer Networking, by Kurose&Ross5: Securing IP 5-18
Security Association (2)
! An SA is uniquely identified by 3 parameters:
" Security Parameters Index (SPI): a bitstring assigned to this SAby the receiver end, and having local significance only. Used toselect the SA under which a received packet will be processed.
" IP Destination Address: can be a router address, can be unicastor multicast.
"
Security Protocol Identifier: indicates whether the association isan AH or ESP SA
! The SPI alone seems to suffice to uniquely identify the SA, but" The same SPI can be assigned to both an ESP SA and an AH SA, so this
security protocol identifier is needed to remove ambiguity
" For multicast, the SPI is chosen by the source, so the destinationaddress field is also needed to remove ambiguity
! Hence, in any IP packet, the SA is uniquely identified by these 3fields
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 10/31
10
© From Computer Networking, by Kurose&Ross5: Securing IP 5-19
Example SA from R1 to R2
R1 stores for SA:! 32-bit identifier for SA: Security Parameter Index (SPI) ! origin SA interface (200.168.1.100)!
destination SA interface (193.68.2.23)! type of encryption used (e.g., 3DES with CBC)! encryption key! type of integrity check used (e.g., HMAC with MD5)! authentication key
193.68.2.23200.168.1.100
172.16.1/24172.16.2/24
security association
Internetheadquartersbranch office
R1R2
© From Computer Networking, by Kurose&Ross5: Securing IP 5-20
! endpoint holds SA state in security association database (SAD) , where it can locate themduring processing
! with n salespersons, 2 + 2n SAs in R1’s SAD
! when sending IPsec datagram, R1 accessesSAD to determine how to process datagram
! when IPsec datagram arrives to R2, R2examines SPI in IPsec datagram, indexes SADwith SPI, and processes datagram accordingly
Security Association Database (SAD)
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 11/31
11
© From Computer Networking, by Kurose&Ross5: Securing IP 5-21
IPsec datagramFocus for now on tunnel mode with ESP
new IP
header
ESP
hdr
original
IP hdr
Original IP
datagram payload
ESP
trl
ESP
auth
encrypted
“enchilada” authenticated
paddingpad
length
next
header SPI
Seq
#
© From Computer Networking, by Kurose&Ross5: Securing IP 5-22
What happens?
new IP
header
ESP
hdr
original
IP hdr
Original IP
datagram payloadESP
trl
ESP
auth
encrypted
“enchilada” authenticated
paddingpad
length
next
header SPI
Seq
#
193.68.2.23200.168.1.100
172.16.1/24172.16.2/24
security association
Internetheadquartersbranch office
R1R2
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 12/31
12
© From Computer Networking, by Kurose&Ross5: Securing IP 5-23
R1 converts original datagraminto IPsec datagram
! Appends to back of original datagram (which includesoriginal header fields!) an “ESP trailer” field
! Encrypts result using algorithm & key specified by SA
! Appends to front of this encrypted quantity the “ESPheader, creating “enchilada”
! Creates authentication MAC over the whole enchilada ,using algorithm and key specified in SA
! Appends MAC to back of enchilada, forming payload ! Creates brand new IP header, with all the classic IPv4
header fields, which it appends before payload
© From Computer Networking, by Kurose&Ross5: Securing IP 5-24
Inside the enchilada:
! ESP trailer: Padding for block ciphers" Next header contains original packet type" Packet type in new IP header is “ESP”
! ESP header:" SPI, so receiving entity knows what to do" Sequence number, to thwart replay attacks
! MAC in ESP auth field is created with shared secret key
new IP
header
ESP
hdr
original
IP hdr
Original IP
datagram payloadESP
trl
ESP
auth
encrypted
“enchilada” authenticated
paddingpad
length
next
header
SPISeq
#
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 13/31
13
© From Computer Networking, by Kurose&Ross5: Securing IP 5-25
IPsec sequence numbers! For new SA, sender initializes seq. # to 0! Each time datagram is sent on SA:
" Sender increments seq # counter" Places value in seq # field
! Goal:" Prevent attacker from sniffing and replaying a packet" Receipt of duplicate, authenticated IP packets may disrupt
service
! Method:" Destination checks for duplicates" But doesn’t keep track of ALL received packets; instead uses
a window
© From Computer Networking, by Kurose&Ross5: Securing IP 5-26
IPsec Anti-Replay in Action
#1#2#3#4
#1#2#4#2#2
#2#2 Packet #3 lost,no problem
Packets #2 are outof sequence and/or
duplicates
R1
R2
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 14/31
14
© From Computer Networking, by Kurose&Ross5: Securing IP 5-27
Packet reordering and IPsecAnti-Replay Window
#1#2#3#4
Packet #1out of sequence.If in window: OK,
otherwise: drop & log
#2#3#4 #1
Networkmay change thepacket order
R1
R2
© From Computer Networking, by Kurose&Ross5: Securing IP 5-28
SA Database (SAD) - More! When sending IPsec datagram, R1 accesses SAD to determine how
to process datagram! When IPsec datagram arrives to R2, R2 examines SPI in IPsec
datagram, indexes SAD with SPI, and processes datagramaccordingly
! Parameters associated with each SA:" AH information: authentication algorithm, keys, key lifetime, …" ESP information: encryption and authentication algorithm, keys,
initialization values, key lifetimes, …" Sequence number counter: used to generate the sequence number field
in AH and ESP headers" Anti-replay window: used to determine whether an inbound AH or ESP
packet is a replay" Lifetime of the SA" Sequence counter overflow flag: indicates what to do when a counter
overflow occurs (usually close the SA)" IPsec protocol mode: tunnel or transport mode" Path MTU: any observed path maximum transmission unit (to avoid
fragmentation)
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 15/31
15
© From Computer Networking, by Kurose&Ross5: Securing IP 5-29
Security Policy Database (SPD)! Policy: For a given datagram, sending entity needs to know if it
should use IPsec" Needs also to know which SA to use
! A nominal Security Policy Database (SPD) defines the means bywhich IP traffic is related to specific SAs (or possibly to no SA)" Info in SPD indicates “what” to do with arriving datagram" Then info in the SAD indicates “how” to do it
! An SPD contains entries, each of which defines a subset of IPtraffic (via some IP and upper-layer protocol field values, calledselectors) and points to an SA for that traffic
! Outbound processing obeys the following general sequence for each
packet:" Compare the values of the appropriate fields in the packet (selector
fields) against the SPD to find a matching SPD entry" Determine the SA associated with that entry (if any) and its associated
SPI" Do the required IPsec processing (i.e. AH or ESP processing)
! Like the packet filter rules in firewalls (see next chapter)
© From Computer Networking, by Kurose&Ross5: Securing IP 5-30
Summary: IPsec services
! Suppose Trudy sits somewhere between R1and R2. She doesn’t know the keys.
! Will Trudy be able to" see contents of original datagram? How about
source, dest IP address, transport protocol,application port?
" flip bits without detection?
" masquerade as R1 using R1’s IP address?
" replay a datagram?
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 16/31
16
© From Computer Networking, by Kurose&Ross5: Securing IP 5-31
Chapter Roadmap
! Security in the network layer
! IPsec - The big picture
! IPsec protocols: AH and ESP
! IPsec Key Exchange protocol: IKE
© From Computer Networking, by Kurose&Ross5: Securing IP 5-32
Transport and Tunnel ModesBrief overview
! Transport mode" Protection of the IP packet payload only" IP header unchanged
! Tunnel mode" Protection of the entire IP packet" To do this, the entire protected original packet is
treated as the payload of a new "outer" IP packet,with a new outer IP header
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 17/31
17
© From Computer Networking, by Kurose&Ross5: Securing IP 5-33
AH - Transport Mode
OriginalIP header
but PT = 51
Auth. headerAH
other headers and payloads
OriginalIP header
other headers and payloads secret key
Digital signature produced by a MAC(Message Authentication Code) algorithm(MD5 or SHA-1)
Original IP datagram
Authenticated IP datagram
Non mutablefields only
Part of the AH header is also authenticated
Partsof
© From Computer Networking, by Kurose&Ross5: Securing IP 5-34
AH - Tunnel Mode
OriginalIP header
Auth. headerAH
other headers and payloads
OriginalIP header
other headers and payloads
secret key
Digital signature produced by a MAC(Message Authentication Code) algorithm(MD5 or SHA-1)
Original IP datagram
Authenticated IP datagram
All fields
New IPheader
New IPheader
built bytunnel end
Non mutablefields only
Part of the AH header is also authenticated
Partsof
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 18/31
18
© From Computer Networking, by Kurose&Ross5: Securing IP 5-35
IPsec AH Header 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Total length = 32 bytesNext header identifies protocol type above IP
The sequence number is used to guard against the replay attack
© From Computer Networking, by Kurose&Ross5: Securing IP 5-36
ESP without AuthenticationTransport Mode
OriginalIP header
but PT = 50ESP header other headers and payloads and ESP trailer
OriginalIP header
other headers and payloads
secret key
Original IP datagram
IP datagram with transport ESP
Encryption algorithm(e.g. DES with CBC)
ESP trailer(padding)
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 19/31
19
© From Computer Networking, by Kurose&Ross5: Securing IP 5-37
ESP without AuthenticationTunnel Mode
new IPheader
ESP header
IP header other headers + payloads
secret key
Original IP datagram
IP datagram with tunnel ESP
IP header other headers + payloads + ESP trailer
new IPheader
built bytunnel end
Encryption algorithm(e.g. DES with CBC)
ESP trailer(padding)
© From Computer Networking, by Kurose&Ross5: Securing IP 5-38
ESP with AuthenticationTransport Mode
OriginalIP header
ESP header other headers + payloads + ESP trailer
OriginalIP header
other headers + payloads
Original IP datagram
IP datagram with transport ESP
ESPauthentication
Encrypted part
Authenticated part
ESP trailer
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 20/31
20
© From Computer Networking, by Kurose&Ross5: Securing IP 5-39
ESP with AuthenticationTunnel Mode
new IPheader
ESP header
IP header other headers + payloads
Original IP datagram
IP datagram with tunnel ESP
IP header other headers + payloads + ESP trailer
ESP trailer
ESPauthentication
Encrypted part
Authenticated part
© From Computer Networking, by Kurose&Ross5: Securing IP 5-40
IPsec ESP format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----| Security Parameters Index (SPI) | ^Auth.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| Sequence Number | |erage+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----| Payload Data* (variable) | | ^~ ~ | || | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| | Padding (0-255 bytes) | |erage*+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad Length | Next Header | v v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------| Authentication Data (variable) |~ ~| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Added length: minimum 8 bytes (+4 bytes IV for DEC-CBC) beforeand minimum 2 bytes after without authentication.
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 21/31
21
© From Computer Networking, by Kurose&Ross5: Securing IP 5-41
Combining authentication andconfidentiality! First method: ESP with authentication
" does not authenticate the non mutable parts of the IP header (intransport mode) or new IP header (in tunnel mode)
" applies encryption before authentication• so authentication applies to the cyphertext, rather than the plaintext
! Second method: ESP (without authentication), then AH" does authenticate the non mutable parts of the IP header" has the disadvantage of using two SAs
! Third method: first AH, then ESP (without authentication)" authentication applies to the plaintext
• allows to store the authentication information together with the message(without having to reencrypt the message to verify the authentication)" the authentication header is protected by encryption" still two SAs
! Usage of AH and ESP can be in transport or tunnel modes
© From Computer Networking, by Kurose&Ross5: Securing IP 5-42
Do we need AH?
! We clearly need ESP for encryption, but do we needAH?
! AH protects the IP header itself. But does IP headerprotection matter?"
If it were necessary, ESP in tunnel mode could provide it" Note that intermediate routers cannot check header
integrity. Why?
" So integrity can only be checked at the other end of the SA
! Note also that, even with AH, an untrusted sourcehost could still spoof its own IP address" Only integrity is ensured
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 22/31
22
© From Computer Networking, by Kurose&Ross5: Securing IP 5-43
IPsec and NAT ! NAT translates the source IP address and the source
port of the IP packet!" A NAT box actually does IP spoofing
! An IPsec SA cannot go through a NAT box" With AH, the integrity check would fail
" With ESP, the port number is encrypted
" And the NAT box doesn’t have the key
! Need to encapsulate IPsec packets in UDP packets:
IP TCPUser
Data
HASHESP
50IP Encrypted Data
IP PayloadUDP
© From Computer Networking, by Kurose&Ross5: Securing IP 5-44
IPSec Tunnels & QoS
new IPheader
ESP header
IP header IP payload
Original IP datagram
IP datagram with ESP tunnel
IP header IP payload
New IP header built by tunnel endTOS byte is copiedTOS byte is copied
TOS / DSCP
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 23/31
23
© From Computer Networking, by Kurose&Ross5: Securing IP 5-45
Chapter Roadmap
! Security in the network layer
! IPsec - The big picture
! IPsec protocols: AH and ESP
! IPsec Key Exchange protocol: IKE
© From Computer Networking, by Kurose&Ross5: Securing IP 5-46
IKE: Internet Key Exchange
! In previous examples, we manually establishedIPsec SAs in IPsec endpoints:Example SA:
SPI: 12345Source IP: 200.168.1.100
Dest IP: 193.68.2.23Protocol: ESPEncryption algorithm: 3DES-cbcHMAC algorithm: MD5Encryption key: 0x7aeaca…
HMAC key:0xc0291f …
! Manual keying is impractical for large VPN with100s of endpoints
! Instead use IPsec IKE (Internet Key Exchange)
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 24/31
24
© From Computer Networking, by Kurose&Ross5: Securing IP 5-47
IKE: PSK and PKI! Authentication (proof of who you are) with either
" pre-shared secret (PSK) or
" with PKI (public/private keys and certificates)
! With PSK: both sides start with secret:" run IKE to authenticate each other and to generate IPsec SAs
(one in each direction), including encryption and authenticationkeys
! With PKI: both sides start with public/private key pair
and certificate:" run IKE to authenticate each other and obtain IPsec SAs (onein each direction)
" Similar with handshake in SSL
© From Computer Networking, by Kurose&Ross5: Securing IP 5-48
IKE - 2 phases - overview! IKE has two phases! Phase 1: establish bi-directional IKE SA
" The two peers establish a secure, authenticated channel with which tocommunicate.
" This is called the IKE Security Association (SA), aka ISAKMP SA• Note: IKE SA is different from IPsec SA
" Based on a Diffie-Hellman (DH) exchange• computationally expensive, but done only once
" Result: one shared key used in (possibly many instances of) phase 2• More precisely, 3 keys are derived from this one (one for IKE encryption,
one for IKE authentication, and one for phase 2)" Phase 1 has two modes: aggressive mode and main mode
! Phase 2: IKE SA is used to securely negotiate IPsec pair of SAs" SAs are negotiated on behalf of services such as IPsec (e.g. AH or
ESP) or any other service which needs key material and/or parameternegotiation
" Uses the 3rd shared secret key (of phase 1) and random numbers tocreate IPsec shared secret keys for AH and ESP SAs
" Those IPsec SAs are unidirectional" Quick procedure and keys can be changed often
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 25/31
25
© From Computer Networking, by Kurose&Ross5: Securing IP 5-49
IKE Phase 1 - Thwarting Clogging
Attacks (1)! DH is computationally expensive! IKE employs a mechanism, known as
cookies, to thwart clogging attacks! The protocol starts by a cookie
request containing a random value (c1)! The other side will send back a cookie
response containing this value (c1) anda new random number (c2)" The only overhead is to send an
acknowledgement, not to perform aDH calculation
" If the source address was forged, theopponent may not get any answer
" If the responder is too busy, it doesnot send acknowledgements
! The returned value (c2) must berepeated in the first message of theDH key exchange
c1
c2, c1
DHparam, c2
Check c2,if OKstarts DH
Gets itonly ifinitial IPaddresswas notspoofed
© From Computer Networking, by Kurose&Ross5: Securing IP 5-50
Thwarting Clogging Attacks(2)
! So, cookies must depend on (i.e. be a hash of) the specific parties(IP source and destination addresses, UDP source anddestination ports) and a locally generated secret value
c1
c2, c1
DHparam, c2
Improvement: Don’t keep a copy of c2.Possible thanks to the fact that the party canrecognise that c2 is one of its own cookies!
But then the scheme is vulnerable to the following attack:
c1
c2, c1
DHparam, c’2
Spoofed IP address
Don’t know c2, butcan use anotherc’2 recorded in arun with my address OK, c’2 is one of my cookies
I start DH
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 26/31
26
© From Computer Networking, by Kurose&Ross5: Securing IP 5-51
DH - Defence against Man-in-the-Middle
(MIM) (1)! If DH parameters (YA and YB) are permanent and public numbers! And if we can be sure that YA and YB are the numbers reliably
associated with A and B respectively" For example, by means of a PKI (Public Key Infrastructure)" That is the pairs (A, YA) and (B, YB) are certified by some trusted
authority" So-called Fixed DH
! Then" The Man-in-the-Middle attack is not possible" And the exchanges of YA and YB can even be eliminated
" B will need to fetch the certified YA only once! But this needs a PKI
" We lose the simplicity of the original Diffie-Hellman scheme
! Also, the fact that YA and YB are permanent makes them morevulnerable to brute-force attacks to find XA and XB
© From Computer Networking, by Kurose&Ross5: Securing IP 5-52
DH - Defence against MIM (2)
! Authenticated (Ephemeral) Diffie-Hellman! If A and B know some sort of secret with which they can
authenticate each other (before running DH)" Knowledge of a (pre-shared) secret key, or" Knowledge of each other’s public key (and their own private key)
! Then they can use this secret to prove it was they who generatedtheir DH values
! Several solutions:" Encrypt the DH exchange with the pre-shared secret key" Sign the transmitted DH value (Y) with own private key" Encrypt the DH value (Y) with the other side’s public key
• Why does it work, knowing that anyone can so encrypt?" Following the DH exchange, transmit a hash of the pre-shared key and
the DH value (Y) you transmitted" Following the DH exchange, transmit a hash of the agreed-upon
shared DH value, your name and the pre-shared key! Again this needs a PKI or a pre-shared key! Note that the DH values can be changed often in this case
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 27/31
27
© From Computer Networking, by Kurose&Ross5: Securing IP 5-53
Back to IKE phase 1 -Authentication! The DH exchange should be authenticated to bar the MIM
attack
! Several authentication methods are used" Authentication with a pre-shared key
" Authentication based on public key cryptography• Authentication with signatures
• Authentication with public key encryption
! But, if one needs public key cryptography anyway, why using DH
to generate a shared secret in the first place?" After all, one party could have generated the secret key and sent it
encrypted with the other party’s public key!
" With DH, both parties contribute to the shared secret/key. So itwill be random if either side has a good random number generator.
© From Computer Networking, by Kurose&Ross5: Securing IP 5-54
IKE phase 1 - main mode
KAB(A, proof I’m A)
Crypto_suite_chosenB
YA
YB
Crypto_suiteA
KAB(B, proof I’m B)
KAB is the calculated DH shared key.Note, both computations in //.
A only reveals her identity here.Moreover, identities are hidden topassive attackers.So, a MIM will only discover A’s id.But could also be hidden. How?
Anonymous DH: no identity revealed,only the IP addresses
Negotiation of the cryptographic methodsused in later exchanges
! Proof of identity: proof that the sender knows the key associated with theidentity, which can be based on" The pre-shared key" The private signature key or encryption key (two pairs of asymmetric keys
are used)! Typically some hash of (1) the key associated with the identity and (2) almost
all fields in previous messages (also provides integrity). With private signaturekeys, the proof can also be a signature on the fields
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 28/31
28
© From Computer Networking, by Kurose&Ross5: Securing IP 5-55
IKE phase 1 - aggressive mode
! Note: in both modes (main and aggressive), nonces are added to messages." The DH shared key is then computed from the DH values AND the nonces" For example: KAB = hash (nonces, standard DH key)
! This allows IKE to reuse the same DH values in successive runs and stillgenerate different shared keys" Protection against replay attack
proof I’m A
B, YB, proof I’m B
A, YA, Crypto_proposalA
Identities revealed, even to passiveattackers: no encryption.
How would you change this modeto hide identities to passive attackers(with public keys)?
Take-it-or-leave-it negotiation.In particular, A chooses a (g,p) pair.
© From Computer Networking, by Kurose&Ross5: Securing IP 5-56
IPsec only authenticates the host!
! If the host is stolen, it can still establishIPsec SAs and connect to a VPN!
! IPsec does not authenticate the user
!
Needs an extra level: user authentication" E.g., IPsec client with Smart card
" Or, extra authentication with username andpassword after IKE phase 1
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 29/31
29
© From Computer Networking, by Kurose&Ross5: Securing IP 5-57
Automated Public Key Exchange
• Peers choose their private/public key pairs" they keep the secret key
" their public keys must be certified
• Use a notary = Certification Authority = CA
• Peer must prove authenticity in front of CA
• Notary signs certificates
• Peers dynamically exchange certificates
• Scalable: n peers requires n authentications and ncertificates
© From Computer Networking, by Kurose&Ross5: Securing IP 5-58
Certificates
• Certificates are not secret
• Common structure ITU X.509 v3 orPKCS#6 (S/MIME, SSL, …)
peer namepeer public keyexpiration dateother info
signatureby the CA
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 30/31
30
© From Computer Networking, by Kurose&Ross5: Securing IP 5-59
How peers work with CA
CA!s own certificate
signed by CA
0. peer generates public/private key pair
1. peer fetchesCA’s certificate
2. peer transmitsits public key
3. peer’s certificatesigned by CA
4. peer fetches
its certificate
Strong or human authenticationStrong or human authenticationneeded for steps 1. and 2.needed for steps 1. and 2.
© From Computer Networking, by Kurose&Ross5: Securing IP 5-60
How to check a certificate?
• Check CA signature" CA’s certificate needed to get CA signature
• Check black list = CRL (Certificate Revocation
List)" connect to CA to get the CRL
• CRL" List of revoked certificates signed by CA
" Stored on CA or directory service
" No requirement on devices to ensure CRL is current
7/23/2019 GSRI-ch5
http://slidepdf.com/reader/full/gsri-ch5 31/31
© From Computer Networking, by Kurose&Ross5: Securing IP 5-61
How to scale CA?A root CA can delegate authentication to lower CA
root CA own certificate signed by root CA
lower CA certificate signed by root CA
router certificate signed by lower CA
certificates chain of routercertificates chain of router
root
lower CA
© From Computer Networking, by Kurose&Ross5: Securing IP 5-62
IPsec: summary
! IKE used to establish sharedsecret keys, algorithms, SPInumbers
! two principal protocols:" authentication header (AH)
protocol
" encapsulation securitypayload (ESP) protocol
! for both AH and ESP, source,destination handshake:" create network-layer logical
channel called a securityassociation (SA)
! Tunnel and transport modes
! shortcomings" IPsec departs from the
pure connectionlessparadigm
" IPsec interferes withNAT boxes
" IPsec only authenticates ahost, not a user
" IPsec is complex: morethan a dozen RFCs