Internet Security CSCE 813 IPsec. CSCE 813 - Farkas2 Reading Today: – Oppliger: IPSec: Chapter 14 – Stalllings: Network Security Essentials, 3 rd edition,

Internet Security Internet Security CSCE 813CSCE 813

IPsecIPsec

CSCE 813 - Farkas 2

ReadingReading

Today: – Oppliger: IPSec: Chapter 14– Stalllings: Network Security Essentials, 3rd

edition, Chapter 6Related readings (not required)– IPSec Architecture RFC 2401– ISAKMP RFC 2408– IKE RFC 2409– HMAC RFC 2104

IPSec OverviewIPSec Overview

IPSec can be added to either IPv4 or IPv6 Supported functionalities: authentication,

confidentiality, and key management Scope of authentication: entire packet (tunnel

mode) or entire packet minus the IP header (transport mode)

Confidentiality: can be supported in either mode. Flexible Key Management

CSCE 813 - Farkas 3

Internet Key ExchangeInternet Key Exchange

CSCE 813 - Farkas 5

IKEIKE Goal: create security association between 2 hosts Two phases:

– 1st phase establishes security association (IKE-SA) for the 2nd phase

Always by authenticated Diffie-Hellman (expensive)– 2nd phase uses IKE-SA to create actual SAs to be used by

AH and ESP Use keys derived in the 1st phase to avoid DH exchange Operates only in “quick” mode

– To create a fresh key, hash old DH value and new nonces

CSCE 813 - Farkas 6

PropertiesProperties

What properties are needed?– Authentication – Secrecy – Forward Secrecy (Perfect FS) – Prevent replay of old key material– Prevent denial of service– Protect identities from eavesdroppers

CSCE 813 - Farkas 7

Key Management in Key Management in IPSecIPSec

Manual key managementSystem administrator manually configures

each system with its own keys – not scalable Automated key management

On-demand creation of keys for the SAs – scalable for large, distributed systems

CSCE 813 - Farkas 8

Internet Key ExchangeInternet Key Exchange

ISAKMP/Oakley– Oakley key determination protocol

Based on Diffie-Hellman Added security (e.g., authentication) Does not dictated specific format

– ISAKMP – Internet Security Association and Key Management Protocol

Framework for key management Specific protocol support (format, negotiation, etc.)

CSCE 813 - Farkas 9

Diffie-Hellman Key ExchangeDiffie-Hellman Key Exchange

Prior agreement of two parameters: g and p A selects random integer a, B selects random integer b Protocol

ga mod p

gb mod p

A B

Alice, Bob compute gab mod p not known to anyone else

CSCE 813 - Farkas 10

Problems with DHProblems with DH

No information about identities Subject to a man-in-the-middle type attack Computationally extensive: vulnerable to a

clogging attack– Attacker sends fake DH messages to a victim from a

forged IP address– Victim starts performing modular exponentiations to

compute a secret key– Victim can be blocked with useless work

CSCE 813 - Farkas 11

Added Security Added Security Features of OakleyFeatures of Oakley

Cookie exchange: thwart clogging attacks– Properties: depends on specific parties, impossible to

anyone else to generate cookies, fast– hash(src IP addr, dst IP addr, src UDP port, dst UDP

port, local secret) Ensure that the responder is stateless until initiator

produced at least 2 messages– Responder’s state (IP addresses and ports) is stored in an un-

forgeable cookie and sent to initiator– After initiator responds, cookie is regenerated and compared with

the cookie returned by the initiator– The cost is 2 extra messages in each execution

CSCE 813 - Farkas 12

Added Security Features of Added Security Features of OakleyOakley

Nonces: detect replay attacksAuthenticates the DH exchange

– Digital signatures, public key encryption, or symmetric key encryption

Support negotiation of the global parameters for the DH exchange – DH groups: global parameters and

identity of algorithms

Key ExchangeKey Exchange

Identities: not secret Derived key: PFS Two modes:

– Main mode: 5 messages, protects IDs– Aggressive mode: 3 messages, does not protect

IDs Multiple variations, see The OAKLEY Key

Determination Protocol, http://tools.ietf.org/html/rfc2412

CSCE 813 - Farkas 13

CSCE 813 - Farkas 14

Aggressive Oakley Aggressive Oakley ExampleExample

– CKYI: I’s cookie– OK_KEYX: key exchange message type– GRP: DH group, gx, gy: public key of init. and resp., gxy: session key

– EHAO/EHAS: encryption, hash, authentication alg. offered/selected– NIDP: indicates encryption is not used for remainder of this message– N: nonce, ID: identifier, – SKI[X]

I R: CKYI ,OK_KEYX , GRP , gx , EHAO , NIDP, IDI , IDR , NI , SKI[ IDI || IDR || NI || GRP || gx || EHAO]

R I: CKYR , CKYI , OK_KEYX , GRP , gy , EHAS , NIDP, IDR , IDI , NR , NI , SKR[ IDR || IDI || NR || NI || GRP || gx || gy || EHAS]

I R: CKYI , CKYR, OK_KEYX , GRP , gx , EHAS, NIDP , IDI , IDR , SKI[ IDI || IDR || NI || NR || GRP || gx || gy || EHAS]

CSCE 813 - Farkas 15

ISAKMP ISAKMP

Defines procedures and packet formats to– Establish – Negotiate– Modify– Delete

security associations

CSCE 813 - Farkas 16

ISAKMP Header FormatISAKMP Header Format

Nextpayload

Mjver

MnVer

Exchangetype

Flags

Message ID

Length

Initiator cookie

Responder cookie

Nextpayload

Reserved Payload length

payload

ISAKMP header

Generic payload header

CSCE 813 - Farkas 17

Payload TypesPayload Types

Security Association (SA) Proposal (P) – info used during SA negotiation, e.g., protocol

type, sender’s SPI, # of transforms Transform (T) – defines the security transform to be used,

transform # (ids the payload), transform id (specific transforms) Key exchange (KE) – key exchange techniques Identification (ID) – identity of the communicating peers Certificate (CR) – public-key certificate (X.509. Kerberos, etc.) Hash (HASH) Signature (SIG) Nonce (NONCE) Notification (N) Delete (D)

CSCE 813 - Farkas 18

Base ExchangeBase Exchange Allows key exchange and authentication material to be transmitted

together Minimizes number of exchanges Does not provide ID protection Protocol:

1. I R : SA; NONCE

2. R I : SA; NONCE

3. I R : KE; IDI; AUTH

4. R I : KE; IDR; AUTH

1-2: cookies + SA establish; nonce: replay protection

3-4: key materials and IDs

CSCE 813 - Farkas 19

Identity Protection ExchangeIdentity Protection Exchange

Expands the Base exchange to protect user IDs. Protocol:

1. I R : SA2. R I : SA3. I R : KE; NONCE4. R I : KE; NONCE5. I R : IDI; AUTH6. R I : IDR; AUTH

1-2: establish SA3-4: key exchange + replay protection5-6: authentication + optional certificate

CSCE 813 - Farkas 20

Authentication Only Authentication Only ExchangeExchange

Perform mutual authentication without key exchange Protocol:

1. I R : SA; NONCE

2. R I : SA; NONCE; IDR; AUTH

3. I R : IDI; AUTH

1-2: establish SA + responder send his/her ID +

authenticate the msg.

3: I’s authenticated ID

CSCE 813 - Farkas 21

Aggressive ExchangeAggressive Exchange

Minimize number of exchanges Does not provide ID protection Protocol:

1. I R : SA; KE; NONCE; IDI

2. R I : SA; KE; NONCE; IDR; AUTH3. I R : AUTH

1:I proposes an SA + begins key exchange + I’s ID. 2: R indicates acceptance of SA + completes key exchange + authentication3: Authentication

CSCE 813 - Farkas 22

Informational Informational ExchangeExchange

One-way transmittal of information for SA management Error or status notification

– Invalid payload type, invalid protocol ID, payload malformed, authentication failed, invalid signature, etc.

– Connected, responder-lifetime, replay status, initial contact Protocol

1. I R : N/D

CSCE 813 - Farkas 23

Next Class: Next Class:

Transport layer securityTransport layer security