1

Chapter 7

Chapter 8Chapter 5

Figure 5.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack

IKE

UDP

2

The system we’ve just described works pretty well if all we’re doing is sending simple messages around, as with e-mail, but it rapidly becomes inadequate if what we want is to have a communications channel over which we can pass arbitrary messages.

A typical design for such a system is to have a handshake phase where Alice and Bob authenticate each other and establish keys. Then they move on to a data transfer phase where they use those keys to actually transmit the data they’re interested in.

We’ll see this in our study of IPSec.The handshake phase protocol is called Internet Key Exchange (IKE)

Excerpt from Rescorla “SSL and TLS”He has described a “simple messaging system” similar to PGP, then he goes on:

We’d like to be able to establish a set of secret keys that we could use for an entire connection. This would let us avoid doing expensive public key operations for every packet, which is especially important in interactive applications where each keystroke might generate a packet.

In Chapter 8 Stallings will leave the handshake phase until last.

3

8.1 IP Security Overview

Applications of IPSec

► Secure branch office connectivity over the Internet (“Virtual Private Network”)

► Secure remote access over the Internet (traveling employees and telecommuters)

► Extranet and Intranet connectivity with partners

► Enhancing E-commerce security (B to B)

Chapter 8 – IP Security

4

* We see that IPsec inserts new headers between the IP header and the IP payload

VPN

VPN*

**BHM ATL

telecommuter

Figure 8.1 An IP Security Scenario

5

Benefits of IPsec

► When IPSec implemented in firewall, all traffic crossing boundary can be protected,

but internal traffic does not suffer overhead of security-related processing

► IPsec in firewall is resistant to bypass (provided firewall is only means of access)

► IPsec transparent to applications

► IPsec can be transparent to end users ("tunnel mode")

► IPsec can provide security for end users if needed ("transport mode")

Routing Applications

Protection of routing updates (recall RIP)

6

IPsec Documents

There are three basic IPsec protocols:

► Authentication Header (AH): AH is an extension header to provide message authentication. Because some authentication is also (optionally) provided in ESP, AH is no longer used much and in the 4th edition Stallings has deleted the section on AH that was in previous editions of the book.

However, he continues to refer to AH in several places, so you need to know that it exists.

► Encapsulating Security Payload (ESP): this provides encryption and optional authentication of messages.

► Internet Key Exchange (IKE): This protocol governs the preliminary handshake phase.

7

IPsec Services

► Access control

► Connectionless integrity

► Data origin authentication

► Rejection of replayed packets

► Confidentiality (encryption)

► Traffic flow confidentiality (in tunnel mode)

8

Transport and Tunnel Modes – overview

Transport Mode provides protection primarily for upper-layer protocols – that is, for the IP datagram payload.

Transport mode is typically used in end-to-end communication between two hosts.

Tunnel Mode extends protection to the entire datagram, by encapsulating it in a new “outer” datagram.

Tunnel mode is typically used in communication between two routers (must be used if a router is involved).

9

You will see this in lab session #2

Tunnel Mode

10

Table 8.1 Tunnel Mode and Transport Mode Functionality

11

Security Associations (SA) (page 276/7) – established during handshake

► SA is a one-way relationship between a sender A and a receiver B that specifies security services to be applied

to a subset of traffic from A to B

► if a peer relationship is desired, we need at least two SAs

► a single SA specifies authentication (AH) XOR encryption (ESP) so we may need 4 SA’s for two-way traffic between A and B

8.2 IP Security Policy

12

Focus on an outbound IP datagram crossing the boundary between an intranet and the Internet.

How is it decided what security processes are applied to this datagram?

This is a policy decision by administration.

The decision for each category of traffic is entered into a Security Policy Database.

The menu of available processes is collected into a

Security Association Database.

Adopt 2-step process - entries in the Security Policy Database point to entries in the Security Association Database.

13Information in the SA database has been agreed to by sender and receiver during the preliminary handshake phase (IKE).

* IP destination address * SPI

14

“A security association is uniquely identified by three parameters:

► Security Parameters Index (SPI)

► IP address of destination endpoint of SA

► IPSec protocol (AH XOR ESP)”

* IP destination address * SPI

15

Summary of relationship between SPD, IKE, and SAD:

Note that SA must first be established between the two IKEs

16

Security Association (SA) Example: Handshaking over secure inter-IKE channel to establish ESP SA from source BHM to destination ATL

BHM

ATL

IKE: negotiate algorithms, develop keys, authenticate participants

This SA uniquely identified by

AH XOR ESP = ESP

SA destination = ATL

SPI = ???

ATL Chooses SPI = 1234

1234

CLT

ATL Chooses SPI = 1235

SPI is unique, local to destination endpoint of SA

SA BHM → ATL established

Want SA

17

Note that BYPASS IPsec is a possible policy for non-sensitive traffic that requires no security processing.

18

Now consider incoming traffic (page 280/1)

IP datagram arrives:

PROTOCOL field = 51 reveals data processed with AH

AH header

51

We’ll see that the IPsec header includes the SPI

DATA

PROTOCOL field = 50 reveals data processed with ESP

19

Consider an IPsec datagram arriving at ATL over our example SA

BHM

ATLThis SA uniquely identified by

AH XOR ESP = ESP

SA destination = ATL

SPI = ???1234

ATL knows that it is ATL!

The other two parameters are readily available to ATL in the incoming datagram headers

Search of incoming SPD is not necessary: ATL can index into SAD

Incoming Traffic – contd.

20

There may be incoming datagrams that were not subjected to IPsec processing – search of incoming

SPD needed to detect intruders.

PROTOCOL = 50 or 51

Index

21

8.3 Encapsulating Security Payload

H

P

T

Initialization Vector

Figure 8.5(a) ESP Packet Format

Optional Integrity Check Value (MAC)

22

Anti-Replay Service

Figure 8.6 Anti-replay Mechanism

23

ESP in transport mode

End-to-end encryption

ESP in transport mode conceals what Alice is saying to Bob, but not that Alice and Bob are communicating.

Alice Bob

24

ESP in tunnel mode

VPN

ESP in tunnel mode over the VPN also conceals the fact that Alice is talking to Bob

Alice

Bob

25

VPNAlice

Bob

26

Original datagram

ESP in transport mode

ESP in tunnel mode

Protocol = 6

Protocol = 50

Protocol = 50

Next = 6

Next = 4

Scope of ESP encryption and authentication

ESP authentication does not extend to the IP header

27

8.4 Combining Security Associations

Since a single SA is tightly focused, it may be necessary to combine more then one to get the desired protection [the new standard, RFC 4301 drops the term security association bundle ].

There are two way to combine SAs:

► Transport adjacency

- apply more than one protocol to a given IP datagram

example: ESP, followed by AH

► tunneling (possibly iterated)

- encapsulation of one datagram inside another

The SAs may terminate at different endpoints, or at the same endpoint.

For example, the previous slide noted that ESP authentication does not extend to the IP datagram header. AP does authenticate the “immutable” (unchanging) fields in the datagram header, so we may need both ESP and AH.

28

Authentication plus confidentiality, using Transport Adjacency

This is simple, but undesirable, because it authenticates the ciphertext

29

Authentication plus confidentiality, using tunneling.

Recall ESP in tunnel mode:

With this scheme, AH authenticates the plaintext

First, apply AH in transport mode:

30

Basic Combinations of Security Associations

Already discussed, and you will see it in lab session #2, section 9

End-to-End Security:

31

You will see this in lab session #2, section 5

VPN

Secure transmission over Internet

32You will see this in lab session #2, section 10

End-to-End Security over VPN:

33

Traveling salesperson or telecommuter communicating over Internet

34

8.5 Internet Key Exchange

Although Stallings presents this at the end of Chapter 8, it actually has to occur before data can be exchanged securely.

The default key automated key management protocol for IPSec consists of two parts (p293):

► Oakley Key Exchange Protocol (development of Diffie-Hellman)

Discuss this next

► Internet Security Association and Key Management Protocol

provides a framework for negotiation of security attributes

Defer to page 296

35

Recall Diffie-Hellman Key Exchange Protocol:

K is the session key that will be used for

symmetric encryption of data transmitted.

Global public parameters q (modulus) and α (generator) already agreed. Y is public key, X is private key.

Key Determination Protocol (Oakley)

36

Diffie-Hellman

Advantages:

► secret keys created only when needed

► exchange requires no pre-existing infrastructure

Disadvantages:

► no authentication of participants

► subject to (wo)man-in-the-middle attacks

► computationally intensive

subject to “clogging attacks” (next slide)

► vulnerable to replay attack (more later)

37

Clogging attack: Darth masquerades as A (trusted by B),

sends YA, triggering extensive computation by B.

38

Features of IKE Key Determination (p294)

1. It uses Cookies to thwart clogging attacks

2. The two parties negotiate use of a group

(the global parameters q and α)

3. It uses Nonces protect against replay attack

4. It enables Diffie-Hellman public key exchange

5. It authenticates the participants

(protects against man-in-the-middle attacks)

39

Cookie requirements (to defend against clogging attacks):

1. Cookie must depend on the two specific parties.

2. Impossible for anyone other than the issuing entity to generate a cookie that will be accepted by that entity (must use local non-shared secret information in

generation and verification)

3. Generation and verification methods must be fast.

Note: ► cookies are not time-dependent

► IKE cookies are not the same as HTTP cookies.

Recommendation for cookies:

Perform a hash over the source and destination IP addresses, the TCP/UDP source and destination ports, and a

locally-generated secret (not shared) value.

40

Use of cookies:

41

Clogging attempt by Darth, from spoofed IP address of A

Darth can force B to generate ACKs, but not to compute DH keys

42

But cookies, not being time-dependent, do not protect against a replay attack

Darth copies messages 1 and 3

1

3

43

Replay Attack: Darth has copied message 1 and after A and B have finished their exchange Darth re-sends message 1 to B.

B thinks this initiates a new exchange and responds as before, sending message 2 to A; A recognizes cookA, but knows she didn’t initiate a new exchange, so she ignores this as a delayed duplicate.

Darth has also copied message 3 and now re-sends it to B.

B recognizes his own cookie, concludes that the exchange is

genuine and computes YB and K – wasted computation.

1

3

44

A nonce is a number used only once.

Replay attack (replay messages 1 and 3) fails,

because B knows he has seen the nonce nA before.

1

45

IKE key determination refers to a group, which is essentially values of the global parameters modulus q and generator α.

Standard groups:

► 1. modular exponentiation (MODP) with 768-bit modulus, α = 2

► 2. modular exponentiation with 1024-bit modulus, α = 2

► 5. modular exponentiation with 1536-bit modulus, α = 2

► two elliptic curve groups (omit)

46

Authentication of Participants

As usual, we have to authenticate the participants.

On page 295/6 Stallings states that three methods can be used with IKE key determination (Oakley.)

► Digital signatures

► Public-Key encryption - encrypt with sender private key

The first two methods appear to be the same

► symmetric-key encryption – manual exchange of secret key

47

IKE

Second part of IKE/Oakley:

IKE is an application layer protocol, using UDP to carry messages.

I think of IKE as a puppeteer, operating above the stage, pulling the strings that set the dials and switches at the IP layer.

ISAKMP refers to Initiator and Responder, since it is controlling Layer 3, where a client-server situation does not exist. Initiator and Responder are peers, both using UDP port 500.

IPsec

48

There are now two versions of IPsec/IKE. Stallings’ pages 294-300 cover IKE version 2, but since we have version 1 in the lab we’ll substitute a handout.

Application Layer (5)

IP Layer (3)

Although this figure refers to IKEv2 and IPsecv3, the basic structure is correct for us.

49

We have seen that before a pair of security gateways can exchange user data protected by IPsec, they must complete a preliminary handshake, the Internet Key Exchange.

During the handshake they authenticate each other and establish algorithms and keys that will be used in subsequent user data transfer.

IKE itself has two phases:

► phase 1: a secure channel, the IKE Security Association pair is set up between the two security gateways

► phase 2: the two gateways use this channel to negotiate safely one or more IPsec SA pairs that will be used to protect transfer of user data between

the two intranets

Both phases must be complete before user data can flow

50

IKE provides two items:

► a collection of message formats

► standard sequences of these messages

to accomplish specific objectives

We consider these in order.

51

First Item: IKE messages consist of a header, followed by one or more payloads

Header format (v1):

For IKE SA establishment Exchangetype will be Identitity Protection Exchange (anti-Darth!)

(a) IKEv1 Header

52

First Item – continued:

IKE Payloads all begin with the generic header:

Types you will see in lab #2 are:

► Security Association payload

► Transform payload

► Key exchange payload

► Identification payload

► Proposal payload

53

Second Item: Standard sequences of messages.

Within IKE there are two phases. Here is more detail:

IKE phase 1:

The Identity Protection Exchange consists of 6 messages:

Messages (1) and (2): Peers negotiate algorithms to be used for establishment of the secure channel between security gateways

Messages (3) and (4) generate the keys to be used

Messages (5) and (6) include authentication of the peers.

54

IKE Phase 2

The secure channel established in phase 1 is used to establish one or more IPSec SA pairs that will subsequently be used to protect user data. We have Darth shut out, so an abbreviated sequence without participant authentication, Quick Mode, is normally used, consisting of just 3 messages.

55

The algorithms to be offered in message (1) and selected in message (2) are:

► the symmetric encryption algorithm

► the hash algorithm to be used in HMAC for message integrity

► the participant authentication method

► the group to be used for Diffie-Hellman/Oakley during session key development

Back to Phase 1 – the Identity Protection Exchange

56

# Initiator Direction Responder NOTE

(1) HDR; SA => Begin ISAKMP-SA

(2) <= HDR; SA Basic SA agreed upon

(3) HDR; KE; NONCE =>

(4) <= HDR; KE; NONCE Key Generated (by Initiator and Responder)

(5) HDR*; ID-I; AUTH => Initiator Identity Verified by Responder

(6) <= HDR*; ID-R; AUTH Responder Identity Verified by Initiator * = payload encrypted

Identity Protection Exchange

At this point the parties have agreed on algorithms

At this point each party has used Diffie-Hellman to securely generate keys. However, the initiator could have been a “man in the middle”

At this point the parties have authenticated themselves to each other and the IKE Security Associations are complete.

57

Proceed to phase 2:

Use the secure channel to establish SAs for user data transfer.

IKE phase 1 finished.

We have a secure channel established between authenticated peers.

58

IKE Phase 2

We could go through the six-message exchange again, checking authentication and producing totally new keys.

Instead, use Quick Mode, which takes just 3 messages.

Quick Mode accepts the choice of algorithms made in phase1.

It also accepts the DH key generated in phase 1, but hashes it to make “new” keys (“new keys from old”)

End of Handshake.

IKE and IPSec Security Associations established.

We can proceed to transmit user data.

59

In the first part of lab session #2 we want to establish a secure tunnel through the “dangerous” network 192.168.6.0 for traffic between 192.168.5.0 and 192.168.7.0

We now take a look at lab #2

60

Recall that IKE consist of two phases:

1. The two “peers” (the encrypting routers X2 and X3) establish a secure, authenticated channel through which to communicate. This is called the “IKE SA”

2. The secure channel established in phase 1 is used to establish one or more “IPsec SAs,” each of which will be

used to protect particular subsets of user traffic flowing between the two subnets.

61

Phase 1 uses the IKEv1 Identity Protection Exchange. According to RFC 2409, the following items must be negotiated:

► the symmetric encryption algorithm

► the hash algorithm to be used in HMAC for message integrity

► the participant authentication method

► the group to be used for Diffie-Hellman/Oakley during session key development

In message #1 the Initiator presents a menu of available sets of these items, and in message #2 the Responder chooses one.

62

Internet Security Association and Key Management Protocol Initiator cookie: 0x46434F49BFDEB5A2 Responder cookie: 0x0000000000000000 Next payload: Security Association (1) Exchange type: Identity Protection (Main Mode) (2) Security Association payload Next payload: Vendor ID (13) Length: 148 Domain of interpretation: IPSEC (1) Situation: IDENTITY (1) Proposal payload # 0 Next payload: NONE (0) Length: 136 Proposal number: 0 Protocol ID: ISAKMP (1) SPI size: 0 Number of transforms: 4 Transform payload # 0 Next payload: Transform (3) Length: 32 Transform number: 0 Transform ID: KEY_IKE (1) Life-Type (11): Seconds (1) Life-Duration (12): Duration-Value (3600) Encryption-Algorithm (1): 3DES-CBC (5) Hash-Algorithm (2): MD5 (1) Authentication-Method (3): RSA-SIG (3) Group-Description (4): 1536 bit MODP group (5) Continues with Transform payloads # 1 - 3

Message #1 – Initiator to Responder

Cookies

(equivalent to SPI)

63

Proposal payload # 0 Next payload: NONE (0) Length: 136 Proposal number: 0 Protocol ID: ISAKMP (1) SPI size: 0 Number of transforms: 4 Transform payload # 0 Next payload: Transform (3) Length: 32 Transform number: 0 Transform ID: KEY_IKE (1) Life-Type (11): Seconds (1) Life-Duration (12): Duration-Value (3600) Encryption-Algorithm (1): 3DES-CBC (5) Hash-Algorithm (2): MD5 (1) Authentication-Method (3): RSA-SIG (3) Group-Description (4): 1536 bit MODP group (5) Transform payload # 1 Next payload: Transform (3) Length: 32 Transform number: 1 Transform ID: KEY_IKE (1) Life-Type (11): Seconds (1) Life-Duration (12): Duration-Value (3600) Encryption-Algorithm (1): 3DES-CBC (5) Hash-Algorithm (2): SHA (2) Authentication-Method (3): RSA-SIG (3) Group-Description (4): 1536 bit MODP group (5) Continues with Transform payloads # 2 & 3

Message #1 - continued

64

Internet Security Association and Key Management Protocol Initiator cookie: 0x46434F49BFDEB5A2 Responder cookie: 0x78B0C0E83C7E8B8A Next payload: Security Association (1) Exchange type: Identity Protection (Main Mode) (2) Security Association payload Next payload: Vendor ID (13) Length: 52 Domain of interpretation: IPSEC (1) Situation: IDENTITY (1) Proposal payload # 0 Next payload: NONE (0) Length: 40 Proposal number: 0 Protocol ID: ISAKMP (1) SPI size: 0 Number of transforms: 1 Transform payload # 0 Next payload: NONE (0) Length: 32 Transform number: 0 Transform ID: KEY_IKE (1) Life-Type (11): Seconds (1) Life-Duration (12): Duration-Value (3600) Encryption-Algorithm (1): 3DES-CBC (5) Hash-Algorithm (2): MD5 (1) Authentication-Method (3): RSA-SIG (3) Group-Description (4): 1536 bit MODP group (5)

Message #2 – Responder to Initiator

Responder chooses transform #0

65

Phase 1 – continued

In lab session #2 the responder’s choice (in message #2) is:

► symmetric encryption algorithm – 3DES-CBC

► hash algorithm – MD5

► participant authentication method – RSA-SIG

► Oakley group – group 5 (1536 bits, α = 2)

Messages #3 and #4 perform the Oakley key exchange

Messages #5 and #6 authenticate parties using RSA-SIG

End of IKE Phase 1 – secure channel established

66

Phase 2: Having set up the secure channel, we can now use it to establish the parameters of an IPSec SA that will govern the cryptographic processing of a particular subset of traffic between the subnets.

As stated before, it would be possible to go through a complete new sequence of procedures (e.g. Diffie-Hellman for key exchange), but this is not necessary over the secure channel.

Instead, an abbreviated procedure is used, simply hashing the keys generated in phase 1. This is called Quick Mode. The Oakley RFC (2412) refers to this as “new keys from old.”

In Quick Mode three messages are exchanged over the secure channel. Since these are encrypted you will not be able to investigate the in the lab.

67

First of 3 quick Mode messages:

Internet Security Association and Key Management Protocol Initiator cookie: 0x46434F49BFDEB5A2 Responder cookie: 0x78B0C0E83C7E8B8A Next payload: Hash (8) Version: 1.0 Exchange type: Quick Mode (32) Flags .... ...1 = Encryption .... ..0. = No commit .... .0.. = No authentication Message ID: 0x6BAA1227 Length: 412 Encrypted payload (384 bytes)

68

End of material on IPsec.

69