Securing Networks Guy Leduc Chapter 5: Network Data Plane ...Securing IP 1 Securing Networks Guy Leduc Chapter 5: Network Data Plane Security: IPsec For a summary, see: Computer Networking:

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


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


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


6


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


IPsec – tunneling mode (2)

❒  Also tunneling mode

IPsec IPsec


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


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


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



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


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


!  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)


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


What happens?

new IP header

ESP hdr

original IP hdr


ESP trl

ESP auth

encrypted


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


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


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


ESP trl

ESP auth

encrypted


padding pad length

next header SPI Seq

#


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


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


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, …)


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


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


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


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


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


IP datagram with ESP tunnel

IP header IP payload

TOS / DSCP

Securing IP 46

Chapter Roadmap


24


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

Documents

Securing Networks Guy Leduc Chapter 5: Network Data Plane ...Securing IP 1 Securing Networks Guy Leduc Chapter 5: Network Data Plane Security: IPsec For a summary, see: Computer Networking: