Internet Protocol Security IPSec

Transcription

1 Internet Protocol Security IPSec Summer Semester 2011 Integrated Communication Systems Group Ilmenau University of Technology

2 Outline Introduction Authentication Header (AH) Encapsulating Security Payload (ESP) Payload Compression Protocol (PCP) Key Management Conclusions Control Questions References 2

3 Introduction 3 3

4 Internet Protocol Security (IPSec) Security framework for IPv4 and IPv6 Provides security for transmission of sensitive information over unprotected networks such as the Internet Provides network security services Data origin authentication Data integrity Data confidentiality Anti-Replay Consists of a couple of separate protocols 4

5 Overview of IPSec Standardization Uses Consists of 5

6 Authentication Header (AH) & Encapsulating Security Payload (ESP) 6 6

7 Authentication Header (AH) IPv4 Before applying AH IPv4 Header Upper Protocol (e. g. TCP, UDP) After applying AH IPv4 Header AH Upper Protocol IPv6 Before applying AH IPv6 Header Hop-by-Hop/Routing Dest. opt. Upper Protocol After applying AH IPv6 Header Hop-by-Hop/Routing AH Dest. opt. Upper Protocol 7

8 Authentication Header (Details) IPv4 header protocol: 51 Next Header Payload Length Reserved Identifies Security Association Against Replay Attack Authentication Security Parameters Index (SPI) Sequence Number Field Data (variable) Upper Protocol 32 bit 8

9 AH Authentication Various authentication methods may be used Used method is negotiated Keyed MD5 (default) Authentication includes IP header (no variable IP options supported) No intermediate authentication when fragmented No encryption! IPv4 Header Upper Protocol Shared secret HASH IPv4 Header AH Upper Protocol 9

10 Encapsulating Security Payload (ESP) IPv4 Before applying ESP IPv4 Header Upper Protocol (e.g. TCP, UDP) After applying ESP IPv4 Header ESP Hdr Upper Protocol ESP Trailer ESP Auth encrypted IPv6 authenticated Before applying ESP IPv6 Header Hop-by-Hop /Routing Dest. opt. Upper Protocol After applying ESP IPv6 Header Hop-by-Hop /Routing ESP Hdr Dest. opt. Upper Protocol ESP Trailer ESP Auth Encryption and authentication No authentication of IP header encrypted authenticated 10

11 Encapsulating Security Payload (Detail) IPv4 header protocol: 50 Identifies Security Association Against Replay Attack Security Parameters Index (SPI) Sequence Number Field Upper Protocol (variable) Padding(0-255 bytes) Authentication Data Pad Length Next Header 32 bit 11

12 Tunnel Mode (IPv4) IPv4 IPv4 Header Upper Protocol Applying AH (authentication only) New IP Header AH IPv4 Header Upper Protocol authenticated except for mutable fields Applying ESP (authentication and encryption) New IP Header ESP Hdr IPv4 Header Upper Protocol ESP Trailer ESP Auth encrypted authenticated 12

13 Tunnel Mode (IPv6) IPv6 IPv6 Header Hop-by-Hop /Routing Dest. opt. Upper Protocol After applying AH (authentication only) New IP Header New ext. Headers AH IPv6 Header Hop-by-Hop /Routing Dest. opt. Upper Protocol authenticated except for mutable fields After applying ESP (authentication and encryption) New IP Header New ext. Headers ESP Hdr IPv6 Header Hop-by-Hop /Routing Dest. opt. Upper Protocol ESP Trailer ESP Auth encrypted authenticated 13

14 AH and ESP Transport Mode Transport mode (protection of payload only) Application of ESP followed by AH IPv4 Header AH ESP Hdr Upper Protocol ESP Trailer ESP Auth Transport mode is used when the cryptographic endpoints are also the communication endpoints of the secured IP packets Cryptographic endpoints: the entities that generate/process an IPSec header (AH or ESP) Communication endpoints: source and destination of an IP packet 14

15 AH and ESP Hierarchies 2 different sequences for authentication and encryption Authentication first, encryption second Internet Encryption first, authentication second Internet 15

16 AH and ESP Scenarios Tunnel mode Used when at least one cryptographic endpoint is not a communication endpoint of the secured IP packets Corporate user works outside corporate network Internet Connecting two sites to a corporate network Internet 16

17 AH and ESP Discussion AH causes smaller CPU overhead than bulk encryption Non-reputation not provided Signing necessary ESP not always necessary Sometimes only packet integrity is need Strong authentication mechanisms are export restricted Minimum requirement for IPv6 is AH 17

18 Payload Compression Protocol (PCP) 18 18

19 Payload Compression Protocol (PCP) Problem: encrypted data cannot be compressed efficiently Encryption introduces randomness PCP reduces IP data size before encryption Hence must be a component of IPSec Increases the overall communication performance 19

20 Overview of Algorithms AH ESP Encryption ESP Auth. PCP MD5 NULL MD5 PCP-LZS SHA DES SHA 3DES AES 20

21 Key Management (credits to the Network Security Institute of Telematics, Karlsruhe Institute of Technology) 21

22 Internet Key Exchange (IKE) Secure negotiation of IPsec parameters IKEv1 was specified by three standard track RFCs IKEv2 is specified by RFC 4306 (Dec. 2005) Goal of Internet Key Exchange Establishing a secure channel ISAKMP (Internet Security Association and Key Management Protocol) Protocol framework for parameter negotiation Defines packet formats Mutual authentication, Diffie-Hellman-Exchange Establishment of IKE-SA (or ISAKMP-SA) (SA = Security Association) Negotiation of IPsec keys Selection of policies and algorithms e.g., authenticate everything and if possible encrypt it, and if possible also compress it, multiple algorithms for each operation Key generation 22

23 IKEv2 Overview IKEv2 is a replacement for IKEv1 IKEv1 very complex and has been discussed controversially IKEv1 provided authentication only based on public key or preshared secret Result: (in-secure) extensions for password authentication E.g., Cisco VPN s XAUTH Improvements in IKEv2 Lower complexity Only one mode compared to 8 modes in IKEv1 Low latency for connection establishment (2x RTT) Modular Authentication using EAP Protection against Denial-of-Service (DoS) attacks by cookies Tunneling of configuration data (no DHCP necessary) Support for NAT-Gateways 23

24 Definitions Security Association (SA) A contract established between two (IPSec) endpoints Represents connection and state Cryptographic material Selection based on SPI SPI: Security Parameter Index Index into table with multiple entries Traffic Selector (TS) New in IKEv2 Describes which traffic should be protected Required to relate traffic to SA E.g.: TCP / IP1:Port1 IP2:Port2 E.g.: UDP / IP-Range:* IP-Range:* 24

25 Initial Exchange IKE_SA_INIT Messages 1 and 2 Selection of algorithms (SA) Diffie-Hellman-Exchange (KEY) Subsequently, IKE-SA is established Encryption and integrity protection now possible Initiator SA i, KEY i, Nonce i SA r, KEY r, Nonce r Responder IKE_AUTH Messages 3 and 4 Validation of identities (ID) Authentication of DH-Exchange (AUTH) Negotiation of Child-SA (SA i2 /SA r2 ) Exchange of traffic selectors (TS i, TS r ) Exchange of certificates (CERTREQ, CERT) ISAKMP payloads contain SA: KEY: Nonce: ID: CERT: CERTREQ: AUTH: TS: [ ] Proposed / selected algorithms Diffie-Hellmann Value (DH) Random number Identity of opposite side Used certificate Request for client certificate Signed hash of authentication messages Traffic selector means optional payload Shared secret generated! Encryption & integrity protection possible: SK{} Initiator SK{ID i, AUTH, [CERT], [CERTREQ],SA i2,ts i,ts r } SK{ID r, [CERT], AUTH, SA r2,ts i,ts r } Responder 25

26 Negotiation of Child-SAs If IKE-SA has been already established, a Child-SA can be directly negotiated for Re-keying or further SAs Formerly known as Phase 2 ( Quick Mode ) in IKEv1 These messages are always secured by IKE-SA channel CREATE_CHILD_SA Messages 1 & 2 Optional: additional DH-Exchange Negotiation of Child-SA (SA i2 /SA r2 ) Again proposal & selection Traffic selectors if new SA Not necessary for re-keying Initiator SK{[N], SA i2, Nonce i, [KEY i ], [TS i, TS r ]} SK{SA r2, Nonce r, [KEY r ], [TS i,ts r ]} Responder ISAKMP-Payloads contain SA: Proposed / selected algorithms KEY: Diffie-Hellmann value (DH) Nonce: Random number N: Notify payload TS: Traffic selector 26

27 Initial Exchange and EAP Messages 1-3 as described above Different starting from message 4 Messages 4-7 comprise modular EAP authentication Message 8 finalizes negotiation of client SA Motivation Extensible Authentication Protocol (EAP) allows for (almost) arbitrary protocols Plug-and-Play authentication Initiator SA i, KEYi, Noncei SAr, KEYr, Noncer Shared secret generated! Encryption & integrity protection possible: SK{} SK{IDi, AUTH, [CERT], [CERTREQ], SAi2,TSi,TSr} SK{IDr,[CERT],AUTH,EAP} SK{EAP} SK{EAP (success)} SK{AUTH} SK{AUTH, SAr2,TSi,TSr} Responder 27

28 IKE Summary IKE IKE-SA Negotiation for channel 1 IKE Negotiation for channel 2 Sets keys for IPsec Secure channel 1 IPsec Sets keys for Secure channel 2 Summary of phases IKE-SA secures negotiation of additional keys Child-SA provides keys for application (e.g., IPsec) Application (e.g., IPsec) secures data exchange 28

29 Conclusions Security architecture for the Internet Protocol Provides the following security services to IP packets: Data origin authentication Confidentiality Replay protection Can be implemented in end systems or intermediate systems Two fundamental security protocols have been defined: Authentication header (AH) Encapsulating security payload (ESP) SA negotiation and key management is realized by Internet security association key management protocol (ISAKMP) Internet key exchange (IKE) 29

30 Control Questions What does IPSec provide? Compare between AH and ESP? Propose applications suitable for each? How can AH and ESP be used in tunnel mode? What are main differences between using each of them in this mode? When should transport mode and tunnel mode be used? Explain briefly the operation of ISAKMP? What are the main advantages when using public key cryptographic with ISAKMP? What are the tasks achieved in phase one of IKE? What is the purpose of phase two? What are the benefits of IKE? 30

31 References Books (related to RFC240x-IPsec from 1998) S. Frankel; Demystifying the IPsec Puzzle; Artech House, 2001 good IPsec-Book (still IKEv1) C. Kaufmann, R. Perlman, M. Speciner; Network Security Private Communication in a public world; Prentice Hall; 2003 more general book Standards und Papers RFC4301 RFC4308 Dez IPsec Standards, IETF recent standards Ferguson, N und Scheier, B.; A Cryptographic Evaluation of IPsec, Feb Simpson, W.; IKE/ISAKMP Considered Dangerous; Draft; Jun RFC 2401 RFC IPsec Standards, IETF old standards 31

32 Contact Integrated Communication Systems Group Ilmenau University of Technology Univ.-Prof. Dr.-Ing. Andreas Mitschele-Thiel Dr. rer. nat. habil. Oliver Waldhorst fon: +49 (0) (2788) fax: +49 (0) Visitors address: Technische Universität Ilmenau Gustav-Kirchhoff-Str. 1 (Informatikgebäude, Room 210) D Ilmenau Integrated Communication Systems Group Ilmenau University of Technology