Internet security and privacy

Transcription

1 Internet security and privacy IPsec 1

2 Layer 3 App. TCP/UDP IP L2 L1 2

3 Operating system layers App. TCP/UDP IP L2 L1 User process Kernel process Interface specific Socket API Device driver 3

4 IPsec Create a secure (privacy, integrity, authentication) IP-layer. Benefits no change made to application layer Drawbacks need to upgrade all operating systems applications can not make use of the authentication 4

5 End-to-end security TCP/UDP IPsec IP L2 L1 TCP/UDP IPsec 5

6 TCP/UDP and IPsec IP TCP/UDP app data IP IPsec TCP/UDP app data 6

7 How hard can it be? Two religious groups push their own idea and the IETF accept both. There are two completely different solutions to IPsec. And each can be operated in two modes. The protocols for initiating a secure connection, IKE RFC 2409, is even more complex and the v2 of the protocol (now an Internet draft) is mainly a simplification of v1. 7

8 Security Association IKE will set up a security association, SA, between two nodes. A SA is one way! The SA includes: cipher algorithm, shared session key, sequence number etc The SA is identified by Security Parameter Index (SPI) chosen by the destination and the destination address Why the destination address? 8

9 Sending and receiving When Alice is sending to Bob: Look up the SA for Bob in a database. Find SPI, algorithm, key, sequence number etc. Include the SPI in the message When Bob receives a message: Lookup the SA based on the destination address and SPI Find algorithm, key, sequence number etc In a multicast message the address is not the address of Bob! 9

10 Two versions AH Authentication Header only provides integrity ESP Encapsulating Security Payload provides integrity and/or privacy 10

11 AH authentication header Let an authentication header implement IP integrity by holding a hash of a shared secret and the content of an IP packet. RFC 2406 How much of the IP packet should be protected? all only the datagram part datagram and part of the IP header Why not all? Why all? 11

12 AH IP header protocol = 51 AH header next = 6/17/?? TCP/UDP/?? Next header Payload length Security Parameter Index Sequence number to detect duplicates Authentication data: HMAC or similar 12

13 What to protect AH is from a school where NAT nodes does not exist and if they existed they should be ignored. Protect as much as possible of the whole IP packet. Why not all? 13

14 things will change Mutable things that are changed by a router Immutable things that a router should not touch Predictable the source knows what the final value will be 14

15 the IP header ver lenght TOS total length identifier fragmentation TTL protocol checksum source address destination address options 15

16 IPv6 In IPv6 the extension headers are all encoded using the same format: next header length of this header data of this header The data field consist of a sequence of type, length, value fields where the type field includes a bit that determines if the value is mutable or immutable. 16

17 mutable/immutable/predictable version header length TOS (DSCP/ECN) total Length identifier fragmentation time to Live (TTL) protocol checksum source address destination address mutable a a a a immutable a a a a a a a predictable a 17

18 What's the problem? App. TCP/UDP IP L2 L1 NAPT NAT A NAT node changes source IP address. NAPT node changes even the source port. In some cases even the application data is changed. 18

19 ESP Encapsulating Security Payload Integrity and encryption (both optional) does not protect the IP header Solves the problem of simple NAT but does not allow NAPT since the port is encoded in the UDP/TCP header. One problem: nothing in the ESP header shows if the payload is encrypted or not. If we don't know we can not determine and filter on the port. 19

20 ESP header/trailer auth encrypted IP header protocol = 50 ESP header TCP/UDP/?? ESP trailer ESP Auth Header Security Param Ind sequence number IV Trailer padding padding length next = 6/17/? Authentication data HMAC or similar 20

21 When to use IPsec Both AH and ESP have problems with NAT, NAPT and firewalls. End user applications does not normally know what the underlying authentication (provided in IKE) means and can not make use of it. Mainly used to set up a secure VPN tunnel between gateways. 21

22 VPN A VPN virtual private network, is set up between two gateways that communicate over an insecure network. Nodes inside the VPN should be able to communicate with each other as if they were inside the same private network. Create a tunnel IP-over-IP between the two gateways and protect the tunnel using IPsec. 22

23 IPsec tunnel mode App. TCP/UDP IP user data IP IP IP L2 L2 IPsec IPsec L2 L1 L1 L2 L2 L1 L1 L1 IPsec IP user data 23

24 IPsec tunnel mode IP header IPsec next=4 IP header Tunnel mode can be implemented using either AH or ESP. The original src/dest address remains intact two private address can talk with each other. User data 24

25 Setting up IPsec IPsec requires a session key and ciphering algorithms. How do we authenticate each other? How do we generate the session key? Which ciphering algorithms should we use? 25

26 IKE Internet Key Exchange setting up the SA's for IPsec? We assume that the two nodes have some long term key (either secret or public) and need to do mutual authentication and create a session key. IKE does not define exactly which ciphers to use, the nodes will negotiate. 26

27 IKE phases Phase 1 do mutual authentication and establish a IKE session key. Phase 2 Set up one ore more IPsec SA between the nodes using the keys derived in phase 1. Why two phases Mutual authentication is expensive so if we need more SAs or need to change SA parameters we do not need to do it again. 27

28 Danger of having only one SA If we only have one SA between two nodes and have several flows going through the nodes (tunnel) Trudy can use one flow to decrypt messages in the other (if encryption only is used). Trudy controls flows between C and D intercept messages: A to B and C to D replace the initial part of the AB message with the initial part of the CD message wait for the decrypted message at D 28

29 Basic set up Propose cipher suite and Diffie- Hellman parameters. Use Diffie-Hellman to create a session key. Use long term secret to authenticate by signing a hash of previous messages. 29

30 Modes of authentication Aggressive mode Mutual authentication and session key in three messages. Main mode Mutual authentication and session key in six messages. More options in cipher negotiation. Can hide endpoint identifiers. 30

31 Main mode Alice crypto proposal crypto choice g a mod p g b mod p {Alice, proof I'm Alice}g ab Bob {Bob, proof I'm Bob}g ab 31

32 Aggressive mode Alice g a mod p, Alice, crypto proposal Bob g b mod p, crypto choice, proof I'm Bob Proof I'm Alice 32

33 Authentication shared secret simplest but with the drawbacks of shared secrets public keys for signatures send a certificate and signed hash of messages to Bob/Alice the natural choice public keys for encryption exchange nonce encrypt with public keys encrypt hash using session key based on nonce Alice can optionaly send certificate 33

34 Phase 2 A three message hand-shake. Protected by session key generated in phase 1 Results in a IPsec Security Association cryptographic methods session keys chosen Security Parameter Index (one for traffic to Alice and one for traffic to Bob) 34