IPsec ( ch 16~18)

26
IPsec IT443 – Network Security Administration Instructor: Bo Sheng 1

description

IPsec ( ch 16~18). IT443 – Network Security Administration Instructor: Bo Sheng. Securing Networks. Applications Layer telnet/ftp: ssh , http: https , mail: PGP. ( SSL/TLS ) Transport Layer (TCP). Network Security Tools: Monitoring/Logging/Intrusion Detection. ( IPSec, IKE ) - PowerPoint PPT Presentation

Transcript of IPsec ( ch 16~18)

Page 1: IPsec  ( ch  16~18)

1

IPsec

IT443 – Network Security AdministrationInstructor: Bo Sheng

Page 2: IPsec  ( ch  16~18)

2

Securing Networks

Link Layer

(IEEE802.1x/IEEE802.10)

Physical Layer

(spread-Spectrum, quantum crypto, etc.)

(IPSec, IKE)

Network Layer (IP)

(SSL/TLS)

Transport Layer (TCP)

Applications Layer

telnet/ftp: ssh, http: https, mail: PGP

Con

trol/M

anag

emen

t (co

nfig

urat

ion)

Net

wor

k Se

curit

y To

ols:

Mon

itori

ng/L

oggi

ng/I

ntru

sion

Det

ectio

n

Page 3: IPsec  ( ch  16~18)

3

IPsec Objectives• Why do we need IPsec?

– IP V4 has no authentication• IP spoofing• Payload could be changed without detection.

– IP V4 has no confidentiality mechanism• Eavesdropping

– Denial of service (DoS) attacks• Cannot hold the attacker accountable due to the

lack of authentication.

Page 4: IPsec  ( ch  16~18)

4

IPsec Objectives• IP layer security mechanism for IPv4 and

IPv6 – Not all applications need to be security aware– Can be transparent to users– Provide authentication and confidentiality

mechanisms.

Page 5: IPsec  ( ch  16~18)

5

IPsec ArchitectureIPsec module 1 IPsec module 2

SPD

IKE

SAD IPsec

SPD

IKE

SADIPsecSA

SPD: Security Policy Database; IKE: Internet Key Exchange;SA: Security Association; SAD: Security Association Database.

Page 6: IPsec  ( ch  16~18)

6

IPsec Architecture• Two Protocols (Mechanisms)

– Authentication Header (AH)– Encapsulating Security Payload (ESP)

• IKE Protocol– Internet Key Management

Page 7: IPsec  ( ch  16~18)

7

IPsec Architecture• Can be implemented in

– Host or gateway • Can work in two Modes

– Tunnel mode– Transport mode

• Hosts can implement IPsec to connect to:– Other hosts in transport or tunnel mode – Or Gateways in tunnel mode

• Gateways to gateways– Tunnel mode

Page 8: IPsec  ( ch  16~18)

8

Authentication Header (AH)• Data integrity

– Entire packet has not been tampered with• Authentication

– Can “trust” IP address source– Use MAC to authenticate

• Anti-replay feature

Page 9: IPsec  ( ch  16~18)

9

Encapsulated Security Protocol (ESP)• Confidentiality for upper layer protocol

• Partial traffic flow confidentiality (Tunnel mode only)

• Data origin authentication and connectionless integrity (optional)

Page 10: IPsec  ( ch  16~18)

10

Tunnel Mode

A B

Encrypted Tunnel

Gateway Gateway

New IP Header

AH or ESP Header

TCP DataOrig IP Header

Encrypted

Unencrypted Unencrypted

Page 11: IPsec  ( ch  16~18)

11

Tunnel Mode

Outer IPheader

Inner IPheader

IPsecheader

Higherlayer protocol

ESP

AH

Real IP destinationDestinationIPsecentity

• ESP applies only to the tunneled packet• AH can be applied to portions of the outer header

Page 12: IPsec  ( ch  16~18)

12

Transport Mode

A B

New IP Header

AH or ESP Header

TCP Data

Encrypted/Authenticated

Page 13: IPsec  ( ch  16~18)

13

Transport Mode

IPheader

IPoptions

IPsecheader

Higherlayer protocol

ESP

AH

Real IPdestination

• ESP protects higher layer payload only• AH can protect IP headers as well as higher layer

payload

Page 14: IPsec  ( ch  16~18)

14

Security Association (SA)• An association between a sender and a receiver

– Consists of a set of security related parameters– E.g., sequence number, encryption key

• One way relationship• Determine IPsec processing for senders• Determine IPsec decoding for destination• SAs are not fixed! Generated and customized

per traffic flows

Page 15: IPsec  ( ch  16~18)

15

Security Parameters Index (SPI) • A 32-bits string assigned to an SA.• Carried in AH and ESP headers to enable

the receiving system to select the SA under which the packet will be processed.

• SPI + Dest IP address + IPsec Protocol– Uniquely identifies each SA in SA Database

(SAD)

Page 16: IPsec  ( ch  16~18)

16

SA Database (SAD)• Holds parameters for each SA

– Sequence number counter– Lifetime of this SA– AH and ESP information– Tunnel or transport mode

• Every host or gateway participating in IPsec has their own SA database

Page 17: IPsec  ( ch  16~18)

17

SA Bundle• More than 1 SA can apply to a packet

• Example: ESP does not authenticate new IP header. How to authenticate?– Use SA to apply ESP w/out authentication to

original packet– Use 2nd SA to apply AH

Page 18: IPsec  ( ch  16~18)

18

Security Policy Database (SPD)• Decide

– What traffic to protect?– Has incoming traffic been properly secured?

• Policy entries define which SA or SA Bundles to use on IP traffic

• Each host or gateway has their own SPD• Index into SPD by Selector fields

– Selectors: IP and upper-layer protocol field values.– Examples: Dest IP, Source IP, Transport Protocol,

IPSec Protocol, Source & Dest Ports, …

Page 19: IPsec  ( ch  16~18)

19

Outbound Processing

Is it for IPsec?If so, which policyentry to select?

SPD(Policy)

SA Database

IP Packet

Outbound packet (on A)

A B

SPI & IPsec Packet

Send to B

Determine the SA and its SPI

IPSec processing

Page 20: IPsec  ( ch  16~18)

20

Inbound Processing

Use SPI to index the SAD

SA Database

Original IP Packet

SPI & Packet

Inbound packet (on B)

A B

From A

SPD(Policy)

Was packet properly secured?

“un-process”

Page 21: IPsec  ( ch  16~18)

21

Issues• Firewalls

– IPsec encrypts information used by firewalls to filter traffic (e.g., port number)

• AH mutable/immutable/predictable fields:– Some fields get modified by the intermediate routers and can’t be

protected by the AH

– Mutable: type of service, flags, fragment offset, TTL, header checksum

– Mutable but predictable fields are included in the AH computation using their expected value at the destination (e.g., destination address even when using source routing)

Page 22: IPsec  ( ch  16~18)

22

Internet Key Exchange• Why do we need Internet key

management– AH and ESP require encryption and

authentication keys

• Process to negotiate and establish IPsec SAs between two entities

Page 23: IPsec  ( ch  16~18)

23

Security Principles• Basic security principle for session keys

– Compromise of a session key• Doesn’t permit reuse of the compromised session key.• Doesn’t compromise future session keys and long-term keys.

• Perfect forward secrecy (PFS)– Compromise of current keys (session key or long-

term key) doesn’t compromise past session keys.– Concern for encryption keys but not for authentication

keys.

Page 24: IPsec  ( ch  16~18)

24

A Note about IKE• IKE v2 was introduced in RFC 4306 (December 2005)

• IKE v2 does not interoperate with IKE v1– Both version can unambiguously run over the same UDP port

• IKE v2 combines the contents of previously separate documents– ISAKMP– IKE v1– DOI– NAT– …

Page 25: IPsec  ( ch  16~18)

25

IKE Overview• A separate RFC has been published for IKE

– RFC 2409• Request-response protocol

– Initiator– Responder

• Two phases– Phase 1: Establish an IKE (ISAKMP) SA

• Essentially the ISAKMP phase 1• Bi-directional

– Phase 2: Use the IKE SA to establish IPsec SAs• Key exchange phase• Directional

Page 26: IPsec  ( ch  16~18)

26

A Clarification About PFS• In RFC 2409:

– When used in the memo Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key.

– The key used to protect transmission of data MUST NOT be used to derive any additional keys.

– If the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys.