securing networks guy leduc chapter 5: network …leduc/cours/isir/secnet-ch5.pdf1 securing ip 1...
Post on 21-Aug-2020
8 Views
Preview:
TRANSCRIPT
1
Securing IP 1
Securing Networks
Guy Leduc
Chapter 5:Network Data Plane Security: IPsec
For a summary, see:
Computer Networking: A Top Down Approach, 7th edition. Jim Kurose, Keith RossAddison-Wesley, April 2016.(section 8.7)
Mainly based on
Network Security - PRIVATE Communication in a PUBLIC World C. Kaufman, R. Pearlman, M. SpecinerPearson Education, 2002.(chapters 17 and 18)
and RFC 7296
Securing IP 2
Chapter 5: Network Data Plane Security
Chapter goals: ❒ security in practice:
❍ Security in the network layer (versus other layers)
❍ Focus on the data plane❍ IPsec and its use in VPNs
2
Securing IP 3
Chapter Roadmap
❒ Security in the network layer❒ IPsec - The big picture❒ IPsec protocols: AH and ESP❒ IPsec Key Exchange protocol: IKE
Securing IP 4
Relative Location of Security Facilities 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 process to
application process❍ “Blanket coverage”
HTTP FTP SMTP
TCP / UDP
IP / IPsec
HTTP FTP SMTP
SSL / TLS
TCP
IPSecurity at network level
Security at transport level
3
© From Computer Networking, by Kurose&RossSecuring IP 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 sent over public Internet instead ❍ Encrypted before entering public Internet❍ Logically separate from other traffic
© From Computer Networking, by Kurose&RossSecuring IP 6
IP header
IPsec header
Secure payload
IP
head
er
IPse
c he
ader
Se
cure
pa
yloa
d IP
header
IPsec
header
Secure
payload
IP
head
er
paylo
ad
IP
header payload
headquarters branch office
salesperson in hotel
laptop w/ IPsec
router w/ IPv4 and IPsec
router w/ IPv4 and IPsec
public Internet
Virtual Private Networks (VPNs)
4
Securing IP 7
Three functional areas
❒ IP-level security encompasses the following 3 functional areas:❍ confidentiality
• enables communicating nodes to encrypt messages to prevent eavesdropping by third parties
❍ data integrity, including origin authentication• assures that a received packet was, in fact, transmitted
by the party identified as the source in the packet header• assures that the packet has not been altered• also includes replay attack prevention
❍ key management• secure exchange of keys
Securing IP 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 but fortunately they were also designed to be usable with the current IPv4
❒ IPsec can encrypt and/or authenticate all traffic at the IP level. Thus IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet❍ VPN (Virtual Private Networks)❍ Secure remote access over the Internet❍ Enhancing Extranet and Intranet connectivity with partners❍ Enhancing Electronic Commerce
5
Securing IP 9
Benefits of IPsec❒ When IPsec is implemented in a firewall or router, it
provides strong security that can be applied to all traffic crossing the perimeter
❒ IPsec is below the transport layer and so is transparent to 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
Securing IP 10
Chapter Roadmap
❒ Security in the network layer❒ IPsec - The big picture❒ IPsec protocols: AH and ESP❒ IPsec Key Exchange protocol: IKE
6
© From Computer Networking, by Kurose&RossSecuring IP 11
IPsec Transport Mode
❒ IPsec datagram emitted and received by end-system
❒ Protects upper level protocols
IPsec IPsec
© From Computer Networking, by Kurose&Ross Securing IP 12
IPsec – tunneling mode (1)
❒ End routers are IPsec aware ❒ Hosts need not be
IPsec IPsec
7
© From Computer Networking, by Kurose&Ross Securing IP 13
IPsec – tunneling mode (2)
❒ Also tunneling mode
IPsec IPsec
© From Computer Networking, by Kurose&Ross Securing IP 14
Two IPsec protocols
❒ Authentication Header (AH) protocol❍ provides source authentication & data integrity❍ but not confidentiality
❒ Encapsulation Security Protocol (ESP)❍ provides confidentiality, ❍ and optionally source authentication, data integrity❍ more widely used than AH
8
© From Computer Networking, by Kurose&Ross Securing IP 15
Four combinations are possible!
Host mode with AH
Host mode with ESP
Tunnel mode with AH
Tunnel mode with ESP
Most common and most important
Securing IP 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 x Connectionless integrity x x Data origin authentication x x Rejection of replayed packets x x x Confidentiality x x Limited traffic flow confidentiality x x
9
Securing IP 17
Security associations (SAs) ❒ Before sending data, a virtual connection is
established from sending entity to receiving entity❒ Called “security association (SA)”
❍ SAs are simplex: for only one direction❒ Both sending and receiving entities maintain state
information about the SA❍ Recall that TCP endpoints also maintain state
information❍ IP is connectionless; IPsec is connection-oriented!❍ It does not mean that IPsec establishes a Virtual Circuit
though• Only SA endpoints maintain state, not intermediate nodes
© From Computer Networking, by Kurose&RossSecuring IP 18
IP header
IPsec header
Secure payload
IP
head
er
IPse
c he
ader
Se
cure
pa
yloa
d IP
header
IPsec
header
Secure
payload
IP
head
er
paylo
ad
IP
header payload
headquarters branch office
salesperson in hotel
laptop w/ IPsec
router w/ IPv4 and IPsec
router w/ IPv4 and IPsec
public Internet
How many SAs when n salespersons?
10
Securing IP 19
Security Association (2)❒ An SA is uniquely identified by 3 parameters:
❍ Security Parameters Index (SPI): a bitstring assigned to this SA by the receiver end, and having local significance only. Used to select the SA under which a received packet will be processed. If unknown SPI, drop packet
❍ IP Destination Address: can be a router or host address, can be unicast or multicast
❍ Security Protocol Identifier: indicates whether the association is an 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 destination address
field is also needed to remove ambiguity❒ Hence, in any IP packet, the SA is uniquely identified by these 3 fields
© From Computer Networking, by Kurose&Ross Securing IP 20
Example SA from R1 to R2
R1 stores for SA:o 32-bit identifier for SA: Security Parameter Index (SPI)o origin SA interface (200.168.1.100)o destination SA interface (193.68.2.23)o type of encryption used (e.g., AES with CBC)o encryption keyo type of integrity check used (e.g., HMAC with SHA1)o authentication key
193.68.2.23 200.168.1.100
172.16.1/24 172.16.2/24
security association
Internet headquarters branch office
R1 R2
11
© From Computer Networking, by Kurose&Ross Securing IP 21
! endpoint holds SA state in security association database (SAD), where it can locate them during processing
! when sending IPsec datagram, R1 accesses its SAD to determine how to process datagram
! when IPsec datagram arrives to R2, R2 examines SPI in IPsec datagram, indexes its SAD with SPI, and processes datagram accordingly
Security Association Database (SAD)
© From Computer Networking, by Kurose&Ross Securing IP 22
IPsec datagram
Focus 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
padding pad length
next header SPI Seq
#
12
© From Computer Networking, by Kurose&Ross Securing IP 23
What happens?
new IP header
ESP hdr
original IP hdr
Original IP datagram payload
ESP trl
ESP auth
encrypted
“enchilada” authenticated
padding pad length
next header SPI Seq
#
193.68.2.23 200.168.1.100
172.16.1/24 172.16.2/24
security association
Internet headquarters branch office
R1 R2
© From Computer Networking, by Kurose&Ross Securing IP 24
R1 converts original datagraminto IPsec datagram❒ Appends to back of original datagram (which includes
original header fields!) an “ESP trailer” field❒ Encrypts result using algorithm & key specified by SA❒ Appends to front of this encrypted quantity the “ESP
header”, 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
13
© From Computer Networking, by Kurose&Ross Securing IP 25
Inside the enchilada:
❒ ESP trailer: Padding for block ciphers❍ Next header contains original packet type (“IP”)❍ 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 payload
ESP trl
ESP auth
encrypted
“enchilada” authenticated
padding pad length
next header SPI Seq
#
© From Computer Networking, by Kurose&Ross Securing IP 26
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❍ Note: when a packet is retransmitted (e.g. by TCP), it get a new
IPsec number at SA sending entity ❒ Goal:
❍ Prevent attacker from sniffing and replaying a packet❍ Receipt of duplicate, authenticated IP packets may disrupt service
❒ Method: ❍ Destination checks for duplicates❍ Uses an anti-replay window, which is a range of successive
numbers ending at the largest received sequence number❍ If packet seq # smaller than lower end of window (too old,
assumed received) or if seq # already seen (flagged in window): discard packet
14
Securing IP 27
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
Securing IP 28
Packet reordering and IPsec Anti-Replay Window
#1#2#3#4
Packet #1out of sequence.If in window: OK,
otherwise: drop & log
#2#3#4 #1
Networkmay change the
packet order
R1R2
15
Securing IP 29
Parameters associated with SA Database (SAD)
❒ 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)
Securing IP 30
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 by which 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 IP traffic (via some IP and upper-layer protocol field values, called selectors) and points to an SA for that traffic (or requires to establish one)
❒ 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
16
© From Computer Networking, by Kurose&Ross Securing IP 31
Summary: IPsec services
❒ Suppose Trudy sits somewhere between R1 and 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?
Securing IP 32
Chapter Roadmap
❒ Security in the network layer❒ IPsec - The big picture❒ IPsec protocols: AH and ESP❒ IPsec Key Exchange protocol: IKE
17
Securing IP 33
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
Securing IP 34
AH - Transport Mode
OriginalIP header
but PT = 51Auth. header
AH other headers and payloads
OriginalIP header other headers and payloads secret key
Digital signature produced by a MAC (Message Authentication Code) algorithm (e.g. MD5, SHA-1, …)
Original IP datagram
Authenticated IP datagram
Non mutablefields only
Part of the AH header is also authenticated
Partsof
18
Securing IP 35
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 (e.g. MD5, SHA-1, …)
Original IP datagram
Authenticated IP datagram
All fields
New IP header
New IP header
with PT = 51
built by tunnel end
Part of the AH header is also authenticated
Partsof
Non mutablefields only
Securing IP 36
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next header identifies the type of header immediately following this header(it is “IP” in tunnel mode)Total length = 32 bytes
19
Securing IP 37
ESP without Authentication Transport 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. AES with CBC)
ESP trailer(padding)
Securing IP 38
ESP without Authentication Tunnel Mode
new IP header
with PT = 50ESP header
IP header other headers + payloads
secret key
Original IP datagram
IP datagram with tunnel ESP
IP header other headers + payloads + ESP trailer
new IP header
built by tunnel end
Encryption algorithm(e.g. AES with CBC)
ESP trailer(padding)
20
Securing IP 39
ESP with Authentication Transport Mode
OriginalIP header ESP header other headers + payloads + ESP trailer
OriginalIP header other headers + payloads
Original IP datagram
IP datagram with transport ESP
ESP authentication
Encrypted part
Authenticated part
ESP trailer
Note: ESP header is authenticated, so SPI is authenticated!Therefore source and destination IP addresses, which are linked to the SPI in the SAD, cannot be changed without being detected!
Securing IP 40
ESP with Authentication Tunnel Mode
new IP header ESP header
IP header other headers + payloads
Original IP datagram
IP datagram with tunnel ESP
IP header other headers + payloads + ESP trailer
ESP trailer
ESP authentication
Encrypted part
Authenticated part
21
Securing IP 41
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) |~ ~| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Securing IP 42
Combining authentication and confidentiality❒ First method: ESP with authentication
❍ does not authenticate the non mutable parts of the IP header (in transport mode) or new IP header (in tunnel mode)
• but IP addresses are nevertheless integrity protected through the authenticated SPI!❍ applies encryption before authentication
• so authentication applies to the cyphertext, rather than the plaintext❒ Second method: ESP (without authentication), then AH
❍ ESP SA within AH SA: double encapsulation❍ 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: double encapsulation
❒ Usage of AH and ESP can be in transport or tunnel modes
22
Securing IP 43
Do we need AH?
❒ We clearly need ESP for encryption, but do we need AH?❒ AH protects the IP header itself. But does IP header
protection matter?❍ If it were necessary, ESP in tunnel mode could provide it. Why?
❒ Intermediate routers cannot check header integrity; integrity can only be checked at the receiving end of the SA. Why?❍ So impossible to drop spoofed packet in network
Securing IP 44
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 keys
❒ Need to encapsulate IPsec packets in UDP packets:
IP TCP User Data
HASH ESP 50 IP Encrypted Data
IP Payload UDP
23
Securing IP 45
IPSec Tunnels & QoS
new IP header ESP header
IP header IP payload
Original IP datagram
IP datagram with ESP tunnel
IP header IP payload
TOS / DSCP
Securing IP 46
Chapter Roadmap
❒ Security in the network layer❒ IPsec - The big picture❒ IPsec protocols: AH and ESP❒ IPsec Key Exchange protocol: IKE
24
© From Computer Networking, by Kurose&Ross Securing IP 47
IKE: Internet Key Exchange ❒ In previous examples, we manually established IPsec
SAs in IPsec endpoints:Example SA:
SPI: 12345Source IP: 200.168.1.100Dest IP: 193.68.2.23 Protocol: ESPEncryption algorithm: 3DES-cbcHMAC algorithm: MD5Encryption key: 0x7aeaca…HMAC key:0xc0291f…
❒ Manual keying is impractical for large VPN with 100s of endpoints
❒ Instead use IPsec IKE (Internet Key Exchange)
Securing IP 48
IKE – Introduction❒ IKEv1 was defined in 1998 (RFC 2409)
❍ still in use (e.g. in Android)❒ IKEv2 was defined in 2014 (RFC 7296)
❍ recommended
❒ IKE runs over UDP on port 500 (possibly port 4500)❍ But should be source port agile, in case a NAT box is present
between the 2 peers❍ IKE must accept requests from other ports and reply to these ports
❒ Since UDP is unreliable, ❍ IKE must use timeouts and sequence numbers,❍ to detect packet loss, packet replay, packet forgery, etc.
25
Securing IP 49
IKE – 2 phases – overview❒ IKE has two phases
❍ (phases were used explicitly in IKEv1, they are still implicit in IKEv2)
❒ Phase 1: establish one bi-directional IKE SA❍ The two peers establish a secure, authenticated channel with which to
communicate❍ Initialization step:
• Neither encrypted, nor integrity checked• Negotiation of security parameters• Exchange of nonces• Exchange of (anonymous) Diffie-Hellman (DH) values• Derivation of keys to be used in next step and in phase 2
❍ Authentication step:• Encrypted and integrity checked• Exchange of the identities (initialization step was anonymous)• Exchange of proofs of knowledge of secrets corresponding to the 2 identities
– Based on a pre-shared secret key (PSK) or a PKI (certificates)
❒ Phase 2: IKE SA is used to securely negotiate pairs of IPsec child SAs
Securing IP 50
IKE phase 1 – initialization
2: Crypto_suite_chosenB, YB, NB, SPIB
1: Crypto_suiteA, YA, NA, SPIA
KAB : the calculated DH shared keyNote: both computations in //
❒ Crypto_suite: Proposed security parameters❍ proposed methods for encryption
and integrity protection❍ proposed DH group
(i.e., size of DH keys)❍ proposed Pseudo-Random
Functions (PRF)❒ YA, YB: DH parameters❒ NA, NB: Nonces❒ SPIA, SPIB: IKE SPIs chosen
❒ Anonymous DH is usedo No identity revealed, only the IP addresseso Vulnerable to MIM! But authentication will follow!o Note: YA and YB can be specific to this session (for forward secrecy)
! KAB, NA, NB and the PRF are then used to derive other keys, such as:o a pair for IKE encryption (one per direction), o a pair for IKE integrity protection (one per direction), o one key for phase 2
26
Securing IP 51
IKE phase 1 – authentication
3: KAB(A, proof I’m A)
4: KAB(B, proof I’m B)
A and B reveal their identities.But identities still hidden topassive attackers.A MIM could discover A’s id, though.
❒ Convenient notation: in messages 3 and 4, it is not KAB that is actually used, but the derived keys for encryption and integrity protection
❒ Proof of identity can be based on:❍ The pre-shared key, or❍ The private signature key (certificates can be added to messages 2 and 3)
❒ Proof I’m A:❍ A builds a message containing her identity A and (most fields of) message 1❍ With a PKI, Alice signs it with her private key and only sends the signature❍ With a PSK, Alice sends a MAC of it with the PSK❍ Why is it necessary to use message 1 in signature or MAC?
• 1. Bars downgrade attack on cryto_suite proposed by Alice• 2. Bars MIM attack (see next slide)
MIM attack on IKE
❒ In IKE, NB is also used in the « proof I’m A » to further bind this proof to the current run
❒ Symmetrically NA is also used in the « proof I’m B »© From Computer Networking, by Kurose&Ross
6: Securing IP 5-52
YA, NA
YB, NBYT, NB
YT, NA
KAT(A, proof I’m A) KBT(A, proof I’m A)Derive KAT
Derive KBT Derive KAT and KBT
B detects attack:proof depends on YA (and NA)
present in message 1
Trudy must use YT associated with its secret value XT
Discovers A’s id
27
Securing IP 53
IKE init step – Thwarting Clogging Attacks (1)
❒ DH is computationally expensive❒ IKE employs a mechanism, known as
cookies, to thwart clogging attacks❒ When it detects a large number of half-
open IKE SAs, the responding IKE will not start DH, but send a cookie to the initiator❍ The only overhead is to send an
acknowledgement, not to perform a DH calculation
❍ If the source address was spoofed, the opponent may not get any answer
❒ The cookie must be returned in the retransmitted message 1 of the IKE initialization step
1: Init_req
cookie
1 again + cookie
Check cookie, if OK starts DH
Gets it only if initial IP addresswas not spoofed
Securing IP 54
Thwarting Clogging Attacks(2)
❒ So, cookie must depend on the specific run of the protocol❒ For example the cookie can be a keyed hash of (NA, IPA, SPIA),
where the key is a generated secret that B is the only one to know
1: Init_req
cookie
1 again + cookie
Improvement: To save space in case of DoS attack,B does not want to store copies of its cookies
Makes sense only if B can recognise that a cookie is one of his own cookies!
But then the scheme is vulnerable to the following attack:
Spoofed IP address
Don’t get cookie, but can return anothercookie’ recorded in arun with my address OK, cookie’ is one of my cookies
I start DH
1: Init_req
cookie
1 again + cookie’
28
Securing IP 55
IKE – phase 2 – overview
❒ IKE SA is used to securely negotiate pairs of IPsec child SAs❍ e.g. AH or ESP, or any other service which needs key material
and/or parameter negotiation❒ Uses one of the keys derived in phase 1 and the nonces to
create IPsec shared secret keys for AH or ESP child SAs❒ Those IPsec SAs are unidirectional❒ Quick procedure and keys can be changed often
❍ Little computational cost, only symmetric key crypto
6: KAB (Crypto_suite_chosenB, NB)
5: KAB(Crypto_suiteA, NA)Again, in messages 5 and 6, it is not KAB that is actually used, but the derived keys for encryption and integrity protection
SPIs are also communicatedTraffic selectors as well.
Securing IP 56
IPsec only authenticates the host!
❒ IPsec authenticates the remote peer (router or host), not the final user using the host!
❒ If the host is stolen (e.g. a laptop), it can still establish IPsec SAs and connect to a VPN!
❒ Needs an extra authentication level in some cases (e.g., travelling salesman with laptop): user authentication after IKE phase 1❍ E.g., extra authentication with username and
password❍ Or IPsec client with Smart card
29
Securing IP 57
IPsec: summary❒ IKE used to establish shared
secret keys, algorithms, SPI numbers
❒ Two principal protocols:❍ authentication header (AH)
protocol❍ encapsulation security payload
(ESP) protocol❒ For both AH and ESP, source,
destination handshake:❍ create network-layer logical
channel called a security association (SA)
❒ Tunnel and transport modes
❒ Shortcomings❍ IPsec departs from the pure
connectionless paradigm❍ IPsec may interfere with
NAT boxes❍ IPsec only authenticates a
host, not a user❍ IPsec is even more
complex than explained here
top related