Network Security

1. Network Security

2. Objectives • Brief survey of network security challenges. • Show how network security contributes to and depends on computer security. • Introduction to the design of network security protocols, based on the Internet security protocols IPsec and SSL/TLS. • Network boundaries as security perimeters. • Principles and limitations of firewalls and Intrusion Detection Systems. www.wiley.co.uk/go/gollmann

3. Network Attacks • Passive attacker: listens to traffic (eavesdropping, wiretapping, sniffing). • Active attacker: modifies messages, inserts new messages, corrupts network management information; active attacks are not necessarily more difficult to mount than passive attacks. • Spoofing attack: send messages with forged sender addresses. • Flooding (bombing) attack: large number of messages sent to victim. • Traffic analysis: identify communications patterns; may be possible even when the attacker cannot read individual messages. www.wiley.co.uk/go/gollmann

4. TCP Session Hijacking • Predict challenge to send messages that appear to come from a trusted host. • A spoofs SYN packet from C. • B sends SYN ACK to C. • A guesses the value y+1 to conclude the handshake. A SYN x SYN ACK x+1, y B C A ACK y+1, x+1 B www.wiley.co.uk/go/gollmann

5. TCP SYN Flooding Attacks • Exhaust responder’s resources by creating half-open TCP connection requests. SYN x SYN x y y SYN ACK x+1,y SYN ACK x+1,y SYN x’ y’ ACK y+1, x+1 SYN ACK x’+1,y’ . . . TCP handshake SYN flooding attack www.wiley.co.uk/go/gollmann

6. Protocol Layering Application Application 7 Presentation 5 6 Session 5 TCP Transport 4 4 3 IP Network 3 Network Interface 2 Data Link 2 Hardware Physical 1 1 Internet ISO/OSI 7 layer model www.wiley.co.uk/go/gollmann

7. (N)-PDU (N)-PDU header header payload payload trailer trailer (N-1)-PDU (N-1)-PDU Protocol Layering PDU … Protocol Data Unit www.wiley.co.uk/go/gollmann

8. Implementing Security Services • Header in (N-1)-PDU is convenient location for storing security relevant data. • Upper layer protocol can be aware of lower layer security services: • Upper layer protocol has to change its calls so that they refer to the security facilities provided. • Lower layer security services can be transparent to upper layer protocol: • Upper layer protocol need not be changed at all. www.wiley.co.uk/go/gollmann

9. IPsec • Defined in IETF RFCs 2401–2412. • Provides security at network (Internet) layer. • All IP datagrams covered. • No re-engineering of applications. • Transparent to upper layer. • Mandatory for next generation IPv6, optional for current generation (IPv4). • Two basic modes of use: • Transport mode: IPsec-aware hosts as endpoints. • Tunnel mode: for IPsec-unaware hosts, tunnel established by intermediate gateways or host OS. www.wiley.co.uk/go/gollmann

10. IPsec • Authentication and/or confidentiality services for data: • AH protocol [RFC 2402] • ESP protocol [RFC 2406 ] • Use of AH is being deprecated in favour of ESP. • Political reasons for introducing an authentication-only protocol in the 1990s have faded. • (Too?) flexible set of key establishment methods: • IKE; IKEv2 under development. www.wiley.co.uk/go/gollmann

11. Payload Payload Header Header network IP datagram IP datagram IPsec Transport Mode • Host-to-host (end-to-end) security: • IPsec processing performed at endpoints of secure channel. • Endpoint hosts must be IPsec-aware. www.wiley.co.uk/go/gollmann

12. IPsec Tunnel Mode • Entire IP datagram plus security fields treated as new payload of ‘outer’ IP datagram. • Original ‘inner’ IP datagramencapsulatedwithin ‘outer’ IP datagram. • IPsec processing performed at security gatewayson behalf of endpoint hosts. • Gateway could be perimeter firewall or router. • Gateway-to-gateway but not end-to-end security. • Hosts need not be IPsec-aware. • Encrypted inner IP datagram, including original source and destination addresses, not visible to intermediate routers. www.wiley.co.uk/go/gollmann

13. Payload Payload Header Header Inner IP datagram Inner IP datagram Outer Header Outer Header Header Header Payload Payload IPSec Transport Mode network www.wiley.co.uk/go/gollmann

14. ESP Protocol • Encapsulating Security Payload [RFC 2406]. • Provides one or both of: • confidentiality for payload/inner datagram; sequence number not protected by encryption. • Authentication of payload/inner datagram, but not of outer IP header. • Traffic-flow confidentiality in tunnel mode. • Symmetric encryption and MACs based on secret keys shared between endpoints. www.wiley.co.uk/go/gollmann

15. ESP Headers • ESP specifies header and trailer to be added to IP datagrams. • Header fields include: • SPI (Security Parameters Index): identifies which algorithms and keys are to be used for IPsec processing (more later). • Sequence number. • Trailer fields include: • Any padding needed for encryption algorithm (may also help disguise payload length). • Padding length. • Authentication data (if any), i.e. the MAC value. www.wiley.co.uk/go/gollmann

16. Security Parameters Index (SPI) Sequence Number Payload data (variable) Padding (0 – 255 bytes) Next header Length Authentication Data (variable number of 32-bit words) ESP Header (RFC 2406) www.wiley.co.uk/go/gollmann

17. ESP in transport mode: Original IP header ESP hdr SPI, seqno Payload (e.g. TCP, UDP, ICMP) ESP trlr ESP auth MAC scope Encryption scope ESP in tunnel mode: Outer IP header ESP hdr SPI, seqno Inner IP header Payload (e.g. TCP, UDP, ICMP) ESP trlr ESP auth MAC scope Encryption scope ESP Protocol – Transport & Tunnel www.wiley.co.uk/go/gollmann

18. IPsec Security Policy • IPsec aware hosts need rules for processing packets: • Drop, pass through, encrypt, MAC? • Which key and algorithm to apply? • Rules stored in a Security Policy Database (SPD). • SPD consulted for each outbound and inbound packet. • Fields in packet matched against fields in SPD entries: • Based on source and destination addresses (address ranges), transport layer protocol, transport layer port numbers, … • Match identifies a Security Association (SA), or a group of SAs, or the need for a new SA. www.wiley.co.uk/go/gollmann

19. IPsec Security Association (SA) • A SA is a one-way (simplex) relationship between sender and receiver. • Specifies processing to be applied to this datagram from this sender to this receiver. • List of active SAs held in SA database (SADB). • SA identified by SPI, source address, destination address; contains: • Sequence number counter and anti-replay window, • AH/ESP info: algorithms, IVs, keys, key lifetimes, • SA lifetime, • Protocol mode: tunnel or transport, • … www.wiley.co.uk/go/gollmann

20. Drop, pass through or process packet? Encrypt/MAC using keys from SA Look up SPD to find policy for packet Create new SA if needed More IPsec processing required? Y Pass packet to next instance of IPsec processing N Pass packet down to Link Layer IPsec Outbound Processing www.wiley.co.uk/go/gollmann

21. Combining SAs • IPsec security services may be provided at different points in network. • Host-to-host. • Gateway-to-gateway for Virtual Private Network (VPN). • SAs can be combined using: • Transport adjacency: more than one SA applied to same IP datagram without tunnelling. • Iterated tunnelling: multiple levels of nesting of IPsec tunnels; each level has its own SA; each tunnel can begin/end at different IPsec site along route. www.wiley.co.uk/go/gollmann

22. Inner tunnel Outer Tunnel Local network Internet Security Gateway remote host server Example • Remote host has Internet access to gateway, then gains access to server behind gateway. • Traffic to server protected in inner tunnel. • Outer tunnel protects inner traffic over Internet. www.wiley.co.uk/go/gollmann

23. IPsec Key Management • IPsec needs a lot of symmetric keys: • One key for each SA. • Different SA for each combination of {ESP,AH}  {tunnel,transport}  {sender, receiver}. • Two sources for SAs and keys: • Manual keying: works for small number of nodes but hopeless for reasonably sized networks of IPsec-aware hosts; requires manual re-keying. • IKE: Internet Key Exchange [RFC 2409]; many options and parameters. www.wiley.co.uk/go/gollmann

24. IKE Security Goals • Entity authentication of participating parties. • Establish a fresh shared secret, used to derive further keys: • for protecting IKE management channel, • for SAs for general use. • Secure negotiation of all algorithms. • Authentication method, key exchange method, encryption and MAC algorithms, hash algorithms. • Resistance to Denial-of-Service attacks: cookie mechanism. • Options for perfect forward secrecy, deniable authentication and identity protection. www.wiley.co.uk/go/gollmann

25. IKE Phases • IKE operates in two phases. • Phase 1: Sets up an SA as a secure channel to carry further SA negotiation, plus error and management traffic. • Bi-directional. • ‘Expensive’ entity authentication and key exchange. • Establishes a secure channel for use in Phase 2. • Phase 2: Negotiates SAs for general use. • Fast negotiation over Phase 1 secure channel. • Many Phase 2 runs allowed for each run of Phase 1. • Multiple SAs can be negotiated per run. www.wiley.co.uk/go/gollmann

26. IKE Phase 1 Main Mode: Example Phase 1 main mode using ‘authentication with signatures’ (simplified!) (I=Initiator, R=Responder, […]=optional) 1. IR: HDRi, SA_i 2. RI: HDRr, SA_r 3. IR: HDRi, KE_i, N_i [,Cert_Req] 4. RI: HDRr, KE_r, N_r [,Cert_Req] 5. IR: HDRi*{IDii, [Cert_i,] Sig_i} 6. RI: HDRr*{IDir, [Cert_r,] Sig_r} www.wiley.co.uk/go/gollmann

27. Explanation • Messages 1 and 2: • I and R exchange cookies CKY-I, CKY-R (in HDR fields) and ordered lists of preferred/accepted algorithms (in SA_i, SA_r). • Cookies provide limited anti-DoS measure. • Messages 3 and 4: • Exchange of Diffie-Hellman values (KE_I = gx, KE_r = gy), nonces (N_i, N_r), and request certificates. • Messages 5 and 6: • Exchange of identities, certificates, and signatures on hash of (DH values, nonces, SAs,…). • Everything inside *{…} is encrypted using key SKEYID_ederived fromDH values and nonces. www.wiley.co.uk/go/gollmann

28. SSL

29. SSL/TLS Overview • SSL = Secure Sockets Layer. • unreleased v1, flawed but useful v2, good v3. • TLS = Transport Layer Security [RFC 2246] • TLS1.0 = SSL3.0 with minor tweaks (see later) • SSL/TLS provides security ‘at TCP layer’. • Uses TCP to provide reliable end-to-end transport. • Usually a thin layer between TCP and HTTP. • Applications need to be aware of SSL/TLS.. • Widely used in Web browsers and servers to support ‘secure e-commerce’ over HTTP. www.wiley.co.uk/go/gollmann

30. SSL/TLS Basic Features • SSL Record Protocol: Provides secure, reliable channel to second layer. • Second layer carries SSL Handshake Protocol, Change Cipher Spec. Protocol, Alert Protocol, HTTP, and other application protocols. • SSL Handshake Protocol establishes keys for MAC and encryption at Record Layer. • Different keys in each direction. www.wiley.co.uk/go/gollmann

31. SSL Handshake Protocol – Goals • Entity authentication of participants. • Participants are ‘client’ and ‘server’. • Server nearly always authenticated, client more rarely. • Appropriate for most e-commerce applications. • Establish a fresh, shared secret. • Shared secret used to derive further keys. • For confidentiality and authentication in SSL Record Protocol. • Secure ciphersuite negotiation. • Encryption and hash algorithms • Authentication and key establishment methods. www.wiley.co.uk/go/gollmann

32. Sessions & Connections • Session: • Created by handshake protocol. • Defines set of cryptographic parameters (encryption and hash algorithm, master secret, certificates). • Carries multiple connections to avoid repeated use of expensive handshake protocol. • Connection: • State defined by nonces, secret keys for MAC and encryption, IVs, sequence numbers. • Keys for many connections derived from single master secret created during handshake protocol. www.wiley.co.uk/go/gollmann

33. SSL Handshake Protocol: Run • We sketch the most common use of SSL: • No client authentication. • Client sends pre_master_secretusing Server’s public encryption key from Server certificate. • Server authenticated by ability to decrypt to obtain pre_master_secret, and construct correct finishedmessage. • Other protocol runs are similar. www.wiley.co.uk/go/gollmann

34. SSL Handshake Protocol Run client M1: ClientHello server M2: ServerHello, ServerCertChain, ServerHelloDone M3: ClientKeyExchange, ChangeCipherSpec, ClientFinished M4: ChangeCipherSpec, ServerFinished www.wiley.co.uk/go/gollmann

35. M1: ClientHello • Client initiates connection. • Sends client version number. • 3.1 for TLS. • Sends ClientNonce. • 28 random bytes plus 4 bytes of time. • Offers list of ciphersuites: • Key exchange and authentication options, encryption algorithms, hash functions. • E.g. TLS_RSA_WITH_3DES_EDE_CBC_SHA. www.wiley.co.uk/go/gollmann

36. M2: ServerHello, … • Sends server version number. • Sends ServerNonce and SessionID. • Selects single ciphersuite from list offered by client. • Sends ServerCertChain message. • Allows client to validate server’s public key back to acceptable root of trust. • (optional) CertRequest message. • Omitted in this protocol run – no client authentication. • Finally, ServerHelloDone. www.wiley.co.uk/go/gollmann

37. M3: ClientKeyExchange,… • ClientKeyExchange contains encryption of pre_master_secret under server’s public key. • ChangeCipherSpec indicates that client is updating cipher suite to be used on this session. • Sent using SSL Change Cipher Spec. Protocol. • Optional (only when client is authenticated):ClientCertificate, ClientCertificateVerifymessages. • Finally, ClientFinishedmessage. • MAC on all messages sent so far (both sides). • MAC computed usingmaster_secret. www.wiley.co.uk/go/gollmann

38. M4: ChangeCipherSpec, … • ChangeCipherSpecindicates that server is updating cipher suite to be used on this session. • Sent using SSL Change Cipher Spec. Protocol. • Finally, ServerFinishedmessage. • MAC on all messages sent so far (both sides). • MAC computed using master_secret. • Server can only compute MAC if it can decrypt pre_master_secret in M3. www.wiley.co.uk/go/gollmann

39. SSL Handshake Protocol Run • Is the client authenticated to the server in this protocol run? • No! • Can an adversary learn the value of pre_master_secret? • No! Client has validated server’s public key; To learnpre_master_secretthe server’s private key is needed to decrypt ClientKeyExchange • Is the server authenticated to the client? • Yes! ServerFinished includes MAC on nonces computed using key derived frompre_master_secret. www.wiley.co.uk/go/gollmann

40. SSL/TLS Applications • Secure e-commerce using SSL/TLS. • Client authentication not needed until client decides to buy something. • SSL provides secure channel for sending credit card information. • Client authenticated using credit card information, merchant bears (most of) risk. • Widely deployed (de-facto standard). www.wiley.co.uk/go/gollmann

41. Firewalls

42. Introduction • Cryptographic mechanisms protect data in transit (confidentiality, integrity). • Authentication protocols verify the source of data. • We may also control which traffic is allowed to enter our system (ingress filtering) or to leave our system (egress filtering). • Access control decisions based on information like addresses, port numbers, ... www.wiley.co.uk/go/gollmann

43. Firewall • Firewall: a network security device controlling traffic flow between two parts of a network. • Often installed between an entire organisation’s network and the Internet. • Can also be installed in an intranet to protect individual departments. • All traffic has to go through the firewall for protection to be effective. • Dial-in lines, wireless LANs!? www.wiley.co.uk/go/gollmann

44. Purpose • Firewalls control network traffic to and from the protected network. • Can allow or block access to services (both internal and external). • Can enforce authentication before allowing access to services. • Can monitor traffic in/out of network. www.wiley.co.uk/go/gollmann

45. Types of Firewalls • Packet filter • Stateful packet filter • Circuit-level proxy • Application-level proxy www.wiley.co.uk/go/gollmann

46. Packet Filter • Inspect headers of IP packets, also TCP and UDP port numbers. • Rules specify which packets are allowed through the firewall, and which are dropped. • Actions: bypass, drop, protect(IPsec channel). • Rules may specify source / destination IP addresses, and source / destination TCP / UDP port numbers. • Rules for traffic in both directions. • Certain common protocols are difficult to support securely (e.g. FTP). www.wiley.co.uk/go/gollmann

47. Example • TCP/IP packet filtering router. • Router which can throw packets away. • Examines TCP/IP headers of every packet going through the Firewall, in either direction. • Packets can be allowed or blocked based on: • IP source & destination addresses • TCP / UDP source & destination ports • Implementation on router for high throughput. www.wiley.co.uk/go/gollmann

48. Stateful Packet Filter • Packet filter that understands requests and replies (e.g. for TCP: SYN, SYN-ACK, ACK). • Rules need only specify packets in one direction (from client to server – the direction of the first packet in a connection). • Replies and further packets in the connection are automatically processed. • Supports wider range of protocols than simple packet filter (eg: FTP, IRC, H323). www.wiley.co.uk/go/gollmann

49. Stateful Packet filter & FTP • Client sends ftp-request to server • Firewall stores connection state • FTP-Server Address • state of connection (SYN, ACK, ...) • If correct FTP-server tries to establish data connection, packets are not blocked. www.wiley.co.uk/go/gollmann

50. Circuit-level Proxy • Similar to a packet filter, except that packets are not routed. • Similar to gateway using IPsec in tunnel mode. • Incoming TCP/IP packets accepted by proxy. • Rules determine which connections will be allowed and which blocked. • Allowed connections generate new connection from firewall to server. • Similar specification of rules as packet filter. www.wiley.co.uk/go/gollmann