Managing and Securing

Computer Networks
Guy Leduc

Mainly based on
Network Security - PRIVATE
Communication in a PUBLIC World
C. Kaufman, R. Pearlman, M. Speciner
Pearson Education, 2002.
(chapters 17 and 18)

For a summary, see:

Chapter 5:
Network Layer Security

Computer Networking: A Top Down

Approach,
6th edition.
Jim Kurose, Keith Ross
Addison-Wesley, March 2012.
(section 8.7)

From Computer Networking, by Kurose&Ross

5: Securing IP

5-1

Chapter 5: Network Layer

Security
Chapter goals:
security in practice:
Security in the network layer (versus other layers)
IPsec

From Computer Networking, by Kurose&Ross

5: Securing IP

5-2

Chapter Roadmap
Security in the network layer
IPsec - The big picture
IPsec protocols: AH and ESP
IPsec Key Exchange protocol: IKE

5: Securing IP

From Computer Networking, by Kurose&Ross

5-3

Relative Location of Security

Facilities in the TCP/IP Stack
HTTP

FTP

SMTP

TCP / UDP
IP / IPsec

HTTP

FTP

SMTP

SSL / TLS
TCP
IP

Security at network level

Security at transport level

Both are general-purpose (i.e. application independent) solutions, but

IPsec is NOT specific to TCP

IPsec protects the whole IP payload, including transport headers (e.g. port #)

IPsec is from network entity to network entity, not from application process
to application process

Does work with UDP, and any other protocol above IP (e.g., ICMP, OSPF)
Traffic analysis is thus more difficult (could be web, email, )

Blanket coverage

From Computer Networking, by Kurose&Ross

5: Securing IP

5-4

Virtual Private Networks (VPNs)

Institutions often want private networks for

security

Costly! Separate routers, links, DNS infrastructure

VPN: institutions inter-office traffic is sent

over public Internet instead

Encrypted before entering public Internet

Logically separate from other traffic

5: Securing IP

From Computer Networking, by Kurose&Ross

5-5

Virtual Private Networks (VPNs)

IP
heade
r

Secure
payloa
d

router w/
IPv4 and IPsec

IPsec
heade
r

IP er
ad
he

pa
ylo
ad

e
cur
Se load
y
pa

router w/
IPv4 and IPsec

laptop
w/ IPsec

salesperson
in hotel

ec
IPs der
a
he

IP
heade
r

IPsec
heade
r

IP r
e
ad
he

Secu
re
paylo
ad

public
Internet

I
he P
ad
er

ad
ylo
pa

headquarters
From Computer Networking, by Kurose&Ross

branch office
5: Securing IP

5-6

Three functional areas

IP-level security encompasses the following

3 functional areas:

origin authentication (and data integrity)

assures that a received packet was, in fact,

transmitted by the party identified as the source in
the 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&Ross

5: Securing IP

5-7

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
5: Securing IP
Enhancing Electronic Commerce
From Computer Networking, by Kurose&Ross

5-8

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

From Computer Networking, by Kurose&Ross

5: Securing IP

5-9

5: 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

From Computer Networking, by Kurose&Ross

IPsec Transport Mode

IPsec

IPsec

IPsec datagram emitted and received by

end-system
Protects upper level protocols

From Computer Networking, by Kurose&Ross

5: Securing IP

5-11

5: Securing IP

5-12

IPsec tunneling mode (1)

IPsec

IPsec

End routers are IPsec aware

Hosts need not be

From Computer Networking, by Kurose&Ross

IPsec tunneling mode (2)

IPsec

IPsec

Also tunneling mode

From Computer Networking, by Kurose&Ross

5: Securing IP

5-13

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

From Computer Networking, by Kurose&Ross

5: Securing IP

5-14

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
5: Securing IP

From Computer Networking, by Kurose&Ross

5-15

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
Access Control
Connectionless integrity
Data origin authentication
Rejection of replayed packets
Confidentiality
Limited traffic flow confidentiality
From Computer Networking, by Kurose&Ross

x
x
x
x

ESP
ESP
encryption only encryption+authentication
x
x
x
x

x
x
x
x
x
x
5: Securing IP

5-16

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!

How many SAs in VPN w/ headquarters, branch

office, and n traveling salespeople?

From Computer Networking, by Kurose&Ross

5: Securing IP

5-17

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.
IP Destination Address: can be a router 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

5: Securing IP

5-18

Example SA from R1 to R2
Internet

headquarters

200.168.1.100

R1
172.16.1/24

branch office

193.68.2.23

security association

R2
172.16.2/24

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
From Computer Networking, by Kurose&Ross

5: Securing IP

5-19

Security Association Database (SAD)

endpoint holds SA state in security association
database (SAD), where it can locate them
during processing
with n salespersons, 2 + 2n SAs in R1s SAD
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 datagram accordingly

From Computer Networking, by Kurose&Ross

5: Securing IP

5-20

10

IPsec datagram
Focus for now on tunnel mode with ESP
enchilada authenticated
encrypted
new IP
header

ESP
hdr

SPI

original
IP hdr

Original IP
datagram payload

Seq
#

padding

ESP
trl

ESP
auth

pad
next
length header

5: Securing IP

From Computer Networking, by Kurose&Ross

5-21

What happens?
Internet

headquarters

200.168.1.100

R1

branch office

193.68.2.23

security association

172.16.1/24

R2
172.16.2/24

enchilada authenticated
encrypted
new IP
header

ESP
hdr

SPI

original
IP hdr

Seq
#

From Computer Networking, by Kurose&Ross

Original IP
datagram payload

padding

ESP
trl

ESP
auth

pad
next
length header
5: Securing IP

5-22

11

R1 converts original datagram

into 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

5: Securing IP

From Computer Networking, by Kurose&Ross

5-23

Inside the enchilada:

enchilada authenticated
encrypted
new IP
header

ESP
hdr

SPI

original
IP hdr

Seq
#

Original IP
datagram payload

padding

ESP
trl

ESP
auth

pad
next
length header

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

From Computer Networking, by Kurose&Ross

5: Securing IP

5-24

12

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 doesnt keep track of ALL received packets; instead uses
a window

5: Securing IP

From Computer Networking, by Kurose&Ross

5-25

IPsec Anti-Replay in Action

R1
#4

#3

#2

R2

#1

#2

#2

#2

Packets #2 are out

of sequence and/or
duplicates

From Computer Networking, by Kurose&Ross

#2

#4

#2

#1

Packet #3 lost,
no problem
5: Securing IP

5-26

13

Packet reordering and IPsec

Anti-Replay Window
R1
#4

#3

#2

R2

#1

Network
may change the
packet order

#4

#1

#3

#2

Packet #1
out of sequence.
If in window: OK,
otherwise: drop & log
From Computer Networking, by Kurose&Ross

5: Securing IP

5-27

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 datagram
accordingly
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)

From Computer Networking, by Kurose&Ross

5: Securing IP

5-28

14

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
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&Ross

5: Securing IP

5-29

Summary: IPsec services

Suppose Trudy sits somewhere between R1

and R2. She doesnt 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 R1s IP address?
replay a datagram?

From Computer Networking, by Kurose&Ross

5: Securing IP

5-30

15

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&Ross

5: Securing IP

5-31

Transport and Tunnel Modes

Brief 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

From Computer Networking, by Kurose&Ross

5: Securing IP

5-32

16

AH - Transport Mode
Original IP datagram
Original
IP header

other headers and payloads

secret key

Non mutable
fields only

Digital signature produced by a MAC

(Message Authentication Code) algorithm
(MD5 or SHA-1)

Parts
of
Original
Auth. header
IP header
AH
but PT = 51

other headers and payloads

Authenticated IP datagram

Part of the AH header is also authenticated

5: Securing IP

From Computer Networking, by Kurose&Ross

5-33

AH - Tunnel Mode
Original IP datagram
New IP
header

built by
tunnel end

Original
IP header

Non mutable All fields

fields only

secret key

Digital signature produced by a MAC

(Message Authentication Code) algorithm
(MD5 or SHA-1)

Parts
of
New IP
header

other headers and payloads

Auth. header
AH

Original
IP header

other headers and payloads

Authenticated IP datagram

Part of the AH header is also authenticated

From Computer Networking, by Kurose&Ross

5: Securing IP

5-34

17

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 bytes

Next header identifies protocol type above IP
The sequence number is used to guard against the replay attack
5: Securing IP

From Computer Networking, by Kurose&Ross

5-35

ESP without Authentication

Transport Mode
Original IP datagram
Original
IP header

other headers and payloads

Encryption algorithm
(e.g. DES with CBC)

Original
IP header
but PT = 50

ESP trailer
(padding)

secret key

ESP header other headers and payloads and ESP trailer

IP datagram with transport ESP

From Computer Networking, by Kurose&Ross

5: Securing IP

5-36

18

ESP without Authentication

Tunnel Mode
Original IP datagram
new IP
header

built by
tunnel end

IP header

other headers + payloads

ESP trailer
(padding)

secret key

Encryption algorithm
(e.g. DES with CBC)
new IP
header

ESP header

IP header

other headers + payloads + ESP trailer

IP datagram with tunnel ESP

From Computer Networking, by Kurose&Ross

5: Securing IP

5-37

ESP with Authentication

Transport Mode
Original IP datagram
Original
IP header

other headers + payloads

ESP trailer

Encrypted part

IP datagram with transport ESP

Original
IP header

ESP header

other headers + payloads + ESP trailer

ESP
authentication

Authenticated part
From Computer Networking, by Kurose&Ross

5: Securing IP

5-38

19

ESP with Authentication

Tunnel Mode
Original IP datagram
IP header

other headers + payloads

ESP trailer

Encrypted part

IP datagram with tunnel ESP

new IP
header

ESP header

IP header other headers + payloads + ESP trailer

ESP
authentication

Authenticated part

From Computer Networking, by Kurose&Ross

5: Securing IP

5-39

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)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Payload Data* (variable)
|
~
~
|
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
Padding (0-255 bytes)
|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| Pad Length
| Next Header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication Data (variable)
|
~
~
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---^Auth.
|Cov|erage
| ---|
^
|
|
|Conf.
|Cov|erage*
|
|
v
v
------

Added length: minimum 8 bytes (+4 bytes IV for DEC-CBC) before

and minimum 2 bytes after without authentication.
From Computer Networking, by Kurose&Ross

5: Securing IP

5-40

20

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

authentication applies to the plaintext

Third method: first AH, then ESP (without authentication)

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&Ross

5: Securing IP

5-41

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

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 source

host could still spoof its own IP address

Only integrity is ensured

From Computer Networking, by Kurose&Ross

5: Securing IP

5-42

21

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 doesnt have the key
Need to encapsulate IPsec packets in UDP packets:
IP
ESP
50

IP

IP

UDP

TCP

User
Data

Encrypted Data

HASH

Payload
5: Securing IP

From Computer Networking, by Kurose&Ross

5-43

IPSec Tunnels & QoS

Original IP datagram
IP header

TOS / DSCP

new IP
header

IP payload

New IP header built by tunnel end

TOS byte is copied

ESP header

IP header

IP payload

IP datagram with ESP tunnel

From Computer Networking, by Kurose&Ross

5: Securing IP

5-44

22

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&Ross

5: Securing IP

5-45

IKE: Internet Key Exchange

In previous examples, we manually established

IPsec SAs in IPsec endpoints:

Example SA:
SPI: 12345
Source IP: 200.168.1.100
Dest IP: 193.68.2.23
Protocol: ESP
Encryption algorithm: 3DES-cbc
HMAC algorithm: MD5
Encryption key: 0x7aeaca
HMAC key:0xc0291f

Manual keying is impractical for large VPN with

100s of endpoints
IPsec IKE (Internet Key Exchange)

Instead use

From Computer Networking, by Kurose&Ross

5: Securing IP

5-46

23

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 authentication
keys
With PKI: both sides start with public/private key pair

and certificate:

run IKE to authenticate each other and obtain IPsec SAs (one
in each direction)
Similar with handshake in SSL

From Computer Networking, by Kurose&Ross

5: Securing IP

5-47

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 to

communicate.
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

Result: one shared key used in (possibly many instances of) phase 2

Phase 1 has two modes: aggressive mode and main mode

computationally expensive, but done only once

More precisely, 3 keys are derived from this one (one for IKE encryption,
one for IKE authentication, and one for phase 2)

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 parameter
negotiation
Uses the 3rd shared secret key (of phase 1) and random numbers to
create IPsec shared secret keys for AH and ESP SAs
Those IPsec SAs are unidirectional
Quick procedure and keys can be changed often

From Computer Networking, by Kurose&Ross

5: Securing IP

5-48

24

IKE Phase 1 - Thwarting Clogging

Attacks (1)
DH is computationally expensive

c1

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) and
a new random number (c2)

The only overhead is to send an

acknowledgement, not to perform a
DH calculation
If the source address was forged, the
opponent may not get any answer
If the responder is too busy, it does
not send acknowledgements

Gets it
only if
initial IP
address
was not
spoofed

c2, c1

DHparam, c2
Check c2,
if OK
starts DH

The returned value (c2) must be

repeated in the first message of the

DH key exchange

5: Securing IP

From Computer Networking, by Kurose&Ross

5-49

Thwarting Clogging Attacks(2)

c1
c2, c1
DHparam, c2

Improvement: Dont keep a copy of c2.

Possible thanks to the fact that the party can
recognise that c2 is one of its own cookies!

But then the scheme is vulnerable to the following attack:

Spoofed IP address

c1

Dont know c2, but

can use another
c2 recorded in a
run with my address

c2, c1
DHparam, c2

OK, c2 is one of my cookies

I start DH

So, cookies must depend on (i.e. be a hash of) the specific parties

(IP source and destination addresses, UDP source and

destination ports) and a locally generated secret value

From Computer Networking, by Kurose&Ross

5: Securing IP

5-50

25

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 more

vulnerable to brute-force attacks to find XA and XB

From Computer Networking, by Kurose&Ross

5: Securing IP

5-51

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 others public key (and their own private key)

Then they can use this secret to prove it was they who generated

their 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 sides 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
From Computer Networking, by Kurose&Ross

5: Securing IP

5-52

26

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 partys public key!
With DH, both parties contribute to the shared secret/key. So it
will be random if either side has a good random number generator.

5: Securing IP

From Computer Networking, by Kurose&Ross

5-53

IKE phase 1 - main mode

Crypto_suiteA
Crypto_suite_chosenB
YA
YB
KAB(A, proof Im A)

Negotiation of the cryptographic methods

used in later exchanges
Anonymous DH: no identity revealed,
only the IP addresses
KAB is the calculated DH shared key.
Note, both computations in //.

A only reveals her identity here.

Moreover, identities are hidden to
passive attackers.
So, a MIM will only discover As id.
But could also be hidden. How?
Proof of identity: proof that the sender knows the key associated with the
identity, 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 signature
keys, the proof can also be a signature on the fields
5: Securing IP 5-54
KAB(B, proof Im B)

From Computer Networking, by Kurose&Ross

27

IKE phase 1 - aggressive mode

A, YA, Crypto_proposalA
B, YB, proof Im B

proof Im A

Identities revealed, even to passive

attackers: no encryption.
How would you change this mode
to hide identities to passive attackers
(with public keys)?

Note: in both modes (main and aggressive), nonces are added to messages.

Take-it-or-leave-it negotiation.
In particular, A chooses a (g,p) pair.

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 still
generate different shared keys

Protection against replay attack

From Computer Networking, by Kurose&Ross

5: Securing IP

5-55

IPsec only authenticates the host!

If the host is stolen, it can still establish

IPsec 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 and
password after IKE phase 1

From Computer Networking, by Kurose&Ross

5: Securing IP

5-56

28

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 n

certificates

5: Securing IP

From Computer Networking, by Kurose&Ross

5-57

Certificates
peer name
peer public key
expiration date
other info
signature
by the CA

Certificates are not secret

Common structure ITU X.509 v3 or

PKCS#6 (S/MIME, SSL, )

From Computer Networking, by Kurose&Ross

5: Securing IP

5-58

29

How peers work with CA

3. peers certificate
signed by CA

CAs own certificate

signed by CA
1. peer fetches
CAs certificate

2. peer transmits
4. peer fetches
its public key
its certificate

Strong or human authentication

needed for steps 1. and 2.
0. peer generates public/private key pair
From Computer Networking, by Kurose&Ross

5: Securing IP

5-59

How to check a certificate?

Check CA signature
CAs 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
From Computer Networking, by Kurose&Ross

5: Securing IP

5-60

30

How to scale CA?

A root CA can delegate authentication to lower CA
root
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 router

From Computer Networking, by Kurose&Ross

5: Securing IP

5-61

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)

shortcomings
IPsec departs from the
pure connectionless
paradigm
IPsec interferes with
NAT boxes
IPsec only authenticates a
host, not a user
IPsec is complex: more
than a dozen RFCs

Tunnel and transport modes

From Computer Networking, by Kurose&Ross

5: Securing IP

5-62

31