Chapter 5: Network Layer Security

(1)

Managing and Securing

Computer Networks

Guy Leduc

Chapter 5:

Network Layer Security

For a summary, see:

Computer Networking: A Top Down Approach,

6th_edition.

Jim Kurose, Keith Ross Addison-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)

Chapter 5: Network Layer

Security

Chapter goals:

❒

security in practice:

❍

Security in the network layer (versus other layers)

❍

IPsec

(2)

Chapter Roadmap

❒

Security in the network layer

❒

IPsec - The big picture

❒

IPsec protocols: AH and ESP

❒

IPsec Key Exchange protocol: IKE

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 HTTP FTP SMTP TCP / UDP IP / IPsec HTTP FTP SMTP SSL / TLS TCP IP

Security at network level

(3)

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 header IPse c header Se cure payl oad IP header IP se_c header Se cu_re payl oad IP header payl oad headerIP payl oad salesperson in hotel laptop w/ IPsec router w/ IPv4 and IPsec

router w/ IPv4 and IPsec public

Internet

(4)

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

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

(5)

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

Chapter Roadmap

❒

Security in the network layer

❒

IPsec - The big picture

❒

IPsec protocols: AH and ESP

(6)

IPsec Transport Mode

❒

IPsec datagram emitted and received by

end-system

❒

Protects upper level protocols

IPsec

_IPsec

IPsec – tunneling mode (1)

❒

End routers are IPsec aware

❒

Hosts need not be

(7)

IPsec – tunneling mode (2)

❒

Also tunneling mode

IPsec

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

(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

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

(9)

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?

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

(10)

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.23 200.168.1.100 172.16.1/24 172.16.2/24 security association Internet headquarters branch office R1 R2



endpoint holds SA state in

security association

database (SAD)

, where it can locate them

during processing



with n salespersons, 2 + 2n SAs in R1’s 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

Security Association Database (SAD)

(11)

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 _lengthpad _headernext SPI Seq #

What happens?

padding pad next 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

(12)

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

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

padding _lengthpad _headernext SPI Seq

(13)

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

IPsec Anti-Replay in Action

#1 #2 #3 #4 #1 #2 #4 #2 #2 #2 #2

Packet #3 lost,

no problem

Packets #2 are out

of sequence and/or

duplicates

R1

(14)

Packet reordering and IPsec

Anti-Replay Window

#1 #2 #3 #4

Packet #1

out of sequence.

If in window: OK,

otherwise: drop & log

#2 #3 #4 #1

Network

may change the

packet order

R1

R2

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

(15)

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)

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?

(16)

Chapter Roadmap

❒

Security in the network layer

❒

IPsec - The big picture

❒

IPsec protocols: AH and ESP

❒

IPsec Key Exchange protocol: IKE

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

(17)

AH - Transport Mode

Original IP header but PT = 51 Auth. header

AH other headers and payloads Original

IP 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 mutable fields only

Part of the AH header is also authenticated Parts of

AH - Tunnel Mode

Original IP header Auth. header

AH other headers and payloads Original

IP 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 IP header New IP header built by tunnel end Non mutable fields only

Part of the AH header is also authenticated Parts

(18)

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

ESP without Authentication

Transport Mode

Original IP header

but PT = 50 ESP header other headers and payloads and ESP trailer Original

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

(19)

ESP without Authentication

Tunnel Mode

new IP

header 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 IP

header built by _{tunnel end}

Encryption algorithm

(e.g. DES with CBC)

ESP trailer (padding)

ESP with Authentication

Transport Mode

Original

IP header ESP header other headers + payloads + ESP trailer Original

IP header other headers + payloads

Original IP datagram

IP datagram with transport ESP

ESP authentication

Encrypted part

Authenticated part

(20)

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

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

(21)

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

❒

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

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

(22)

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 TCP User_Data HASH ESP 50 IP Encrypted Data IP UDP Payload

IPSec Tunnels & QoS

new IP

header ESP header

IP header IP payload

Original IP datagram

IP datagram with ESP tunnel

IP header IP payload

New IP header built by tunnel end

TOS byte is copied

(23)

Chapter Roadmap

❒

Security in the network layer

❒

IPsec - The big picture

❒

IPsec protocols: AH and ESP

❒

IPsec Key Exchange protocol: IKE

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

(24)

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

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

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

(25)

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 (c

1

)

❒

The other side will send back a cookie

response containing this value (c

1

) and

a new random number (c

2

)

❍ 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

❒

The returned value (c

₂

) must be

repeated in the first message of the

DH key exchange

c1 c₂, c₁ DHparam, c2 Check c2, if OK starts DH Gets it only if initial IP address was not spoofed

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 and

destination ports) and a locally generated secret value

c₁ c2, c1

DHparam, c₂

Improvement: Don’t keep a copy of c2.

Possible thanks to the fact that the party can recognise that c₂ is one of its own cookies! But then the scheme is vulnerable to the following attack:

c1 c₂, c₁

DHparam, c’₂ Spoofed IP address

Don’t know c2, but can use another c’2 recorded in a

run with my address OK, c’2 is one of my cookies I start DH

(26)

DH - Defence against Man-in-the-Middle

(MIM) (1)

❒

If DH parameters (Y

_A

and Y

_B

) are permanent and public numbers

❒

And if we can be sure that Y

_A

and Y

_B

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, Y_A) and (B, Y_B) are certified by some trusted

authority

❍ So-called Fixed DH

❒

Then

❍ The Man-in-the-Middle attack is not possible

❍ And the exchanges of Y_A and Y_B can even be eliminated ❍ B will need to fetch the certified Y_A only once

❒

But this needs a PKI

❍ We lose the simplicity of the original Diffie-Hellman scheme

❒

Also, the fact that Y

_A

and Y

_B

are permanent makes them more

vulnerable to brute-force attacks to find X

A

and X

B

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

(27)

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 it will be random if either side has a good random number generator.

IKE phase 1 - main mode

K_AB(A, proof I’m A) Crypto_suite_chosenB

YA YB

Crypto_suite_A

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 to passive 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 methods used in later exchanges

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

(28)

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: K_AB = 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

proof I’m A B, Y_B, proof I’m B

A, YA, Crypto_proposalA

Identities revealed, even to passive attackers: no encryption.

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

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

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

(29)

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

Certificates

• Certificates are not secret

• Common structure ITU X.509 v3 or

PKCS#6 (S/MIME, SSL, …)

peer name

peer public key expiration date other info signature by the CA

(30)

How peers work with CA

CAʼs own certificate signed by CA

0. peer generates public/private key pair 1. peer fetches

CA’s certificate

2. peer transmits its public key

3. peer’s certificate signed by CA

4. peer fetches its certificate

Strong or human authentication

needed for steps 1. and 2.

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

(31)

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 router

root lower CA

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 interferes with

NAT boxes

❍

IPsec only authenticates a

host, not a user

❍