1 Chapter 8 Panko, Corporate Computer and Network Security Copyright 2004 Prentice-Hall Cryptographic Systems: SSL/TLS, VPNs, and Kerberos

2 Figure 8-1: Cryptographic System Phase 1: Initial Negotiation of Security Parameters Phase 2: Mutual Authentication Client PC Server Phase 3: Key Exchange or Key Agreement Three Initial “ Hand-Shaking ” Phases

3 Figure 8-1: Cryptographic System Phase 4: Ongoing Communication with Message-by-Message Confidentiality, Authentication, and Message Integrity Client PC Server The Initial Hand-Shaking Stages are Very Brief Almost All Messages are Sent During the Ongoing Exchange Phase

4 Figure 8-2: Major Cryptographic Systems Application Layer Transport Internet Data Link Physical PPTP, L2TP (really only a tunneling system) Not applicable. No messages are sent at this layer — only individual bits IPsec SSL/TLS Kerberos Cryptographic System

5 Figure 8-3: Virtual Private Network (VPN) VPN Server Protected Server VPN Server Protected Server Corporate Site A Corporate Site B Internet Remote Customer or Supplier PC Remote Corporate PC Remote Access VPN Remote Access VPN Site-to-Site VPN

6 Virtual Private Network (VPN) Server Host-to-Host VPN Hosts can communicate Directly with each other Client-Server Client-Client Internet New Not in Book

7 Secure Sockets Layer / Transport Layer Security (SSL/TLS) Protects All Application Traffic That is SSL/TLS-Aware SSL/TLS Works at Transport Layer Applicant (Customer Client) Verifier (Merchant Server)

8 Figure 8-4: SSL/TLS Operation Applicant (Customer Client) Verifier (Merchant Server) 1. Negotiation of Security Options (Brief) 2. Merchant Authenticates Self to Customer Uses a Digital Certificate Customer Authentication is Optional and Uncommon

9 Figure 8-4: SSL/TLS Operation Applicant (Customer Client) Verifier (Merchant Server) 3. Client Generates Random Session Key Client Sends Key to Server Encrypted with Public Key Encryption 4. Ongoing Communication with Confidentiality and Merchant Digital Signatures

10 SSL/TLS Growing rapidly in popularity for remote access  Easy to implement Webservers already implement it Clients already have browsers If only using HTTP, very easy Becoming popular

11 Figure 8-5: Point-to-Point Protocol (PPP) and RADIUS for Dial-Up Remote Access RADIUS Server RAS 1 RAS 2 Remote Corporate PC Remote Corporate PC Public Switched Telephone Network Corporate Site A 2. OK? 1. Login Username And Password Dial-Up Connection Dial-Up Connection 2. OK? RAS = Remote Access Server

12 Figure 8-5: Point-to-Point Protocol (PPP) and RADIUS for Dial-Up Remote Access RADIUS Server RAS 1 RAS 2 Remote Corporate PC Remote Corporate PC Public Switched Telephone Network Corporate Site A 3. OK4. Welcome Dial-Up Connection Dial-Up Connection 3. No 4. Refuse

13 Figure 8-6: PPP Authentication No Authentication Is an Option Client Server

14 Figure 8-6: PPP Authentication Password Authentication Protocol (PAP) Authentication-Request Messages (Send Until Response) Authentication-Response Message Client Server Poor Security: Usernames and Passwords Are Sent in the Clear Authenticate Once

15 Figure 8-6: PPP Authentication CHAP Authentication Challenge Message Response Message Hash (Challenge Message + Secret) Client Server Server computes hash of challenge message plus secret If equals the response message, authentication is successful (Authentication done periodically)

16 Figure 8-6: PPP Authentication MS-CHAP Authentication Challenge Message Response Message Hash (Challenge Message + Password) Client Server CHAP, but with password as the secret. Widely used because allows password authentication Standard on Microsoft Windows client Only as secure as password strength

17 Figure 8-6: PPP Authentication Extensible Authentication Protocol (EAP) Authenticate Defer authentication; Will provide more information Client Server EAP defers authentication to a later process Such as RADIUS authentication

18 Figure 8-7: PPP Encryption New PPP Header. Plaintext. Original PPP Frame. Encrypted. New PPP Trailer. Plaintext.

19 Figure 8-7: PPP Encryption IETF Specifies DES and 3DES for PPP encryption Microsoft uses Microsoft Point-to-Point Encryption (MPPE) for its remote access servers Increasingly, AES is being incorporated into PPP products

20 Figure 8-8: PPP on Direct Links and Internets Connection over Direct Link PPP Provides End-to-End Link PPP Frame Verifier (Server) Applicant (Client)

21 Figure 8-8: PPP on Direct Links and Internets Connection over Internet PPP Frame in IP Packet PPP Limited to First Data Link (Network) Verifier (Server) Applicant (Client) Router The PPP frame is encapsulated in an IP packet. This is the opposite of the normal practice The packet is carried in a separate Frame in each network along the route

22 Figure 8-8: PPP on Direct Links and Internets Note: Tunneling Places the PPP Frame in an IP Packet, Which Delivers the Frame. To the Receiver, Appears to be a Direct Link. Allows organization to continue using existing PPP-based security such as encryption and authentication

23 Figure 8-9: Point-to-Point Tunneling Protocol (PPTP) RADIUS Server PPTP RAS ISP PPTP Access Concentrator Corporate Site A IP Protocol 47 (GRE) Data Connection TCP Port 1723 Supervisory Connection (Vulnerable) Internet Remote Corporate PC Local ISP Access (Not Secure) GRE = Generic Routing Encapsulation

24 Figure 8-9: Point-to-Point Tunneling Protocol (PPP) RADIUS Server PPTP RAS Corporate Site A IP Protocol 47 (GRE) Data Connection TCP Port 1723 Supervisory Connection (Vulnerable) Internet Remote Corporate PC Direct connection between PC and RAS

25 Figure 8-10: PPTP Encapsulation for Data Frames Enhanced Generic Routing Encapsulation (GRE) Header; Information About Encapsulated Packet New IP Header; Protocol=47; IP Destination Address Is That of Remote Access Server Encapsulated Original Frame

26 Figure 8-11: Layer 2 Tunneling Protocol (L2TP) Internal Server L2TP RAS DSL Access Multiplexer (DSLAM) with L2TP Client Running PPP Carrier Network Local Network L2TP Tunnel DSL Note: L2TP does not provide security. It provides only tunneling. L2TP recommends the use of IPsec for security.

27 Figure 8-12: IPsec Operation: Tunnel and Transport Modes Secure Connection Secure on the Internet Transport Mode Site Network Site Network Security in Site Network Security in Site Network Extra Software Required Extra Software Required

28 Figure 8-12: IPsec Operation: Tunnel and Transport Modes Tunneled Connection Secure on the Internet Tunnel Mode Site Network Site Network No Security in Site Network No Security in Site Network No Extra Software No Extra Software IPsec Server IPsec Server

29 Figure 8-12: IPsec Operation: Tunnel and Transport Modes Transport Mode Orig. IP Hdr IPsec Hdr Protected Packet Data Field Destination IP Address Is Actual Address; Vulnerable to Scanning Tunnel Mode New IP Hdr IPsec Hdr Protected Original Packet Destination IP Address is IPsec Gateway Address Host IP Address Is not Revealed

30 Figure 8-13: IPsec ESP and AH Protection IP Header ESP Header Protected ESP Trailer IP Header Authentication Header Protected Confidentiality Authentication and Message Integrity No Confidentiality Protocol = 50 Protocol = 51 Encapsulating Security Payload Authentication Header

31 Modes and Protections ESP Confidentiality Authentication Integrity AH Authentication Integrity Transport Mode (End-to-End) Possible Tunnel Mode (IPsec Gateway to Gateway) Possible

32 Figure 8-14: IPsec Security Associations IPsec Policy Server 2. Security Association (SA) for Transmissions from A to B 3. Security Association (SA) For Transmission from B to A (Can Be Different Than A to B SA) Party A Party B 1. List of Allowable Security Associations 1. List of Allowable Security Associations

33 Figure 8-15: Establishing IPsec Security Associations Using IKE Internet Key Exchange Security Association UDP Port 500 Party A Party B IPsec SAs First establish IKE association and protected session Then create IPsec SAs within the Protection of the IKE session.

34 IPsec Defaults When SA agreement cannot be reached, the two parties will use these defaults:  Diffie-Hellman Key Agreement  DES-CBC  HMAC for Message-by-Message Authentication

35 Figure 8-16: Key-Hashed Message Authentication Codes (HMACs) Shared Key HMAC Original Plaintext Key-Hashed Message Authentication Code (HMAC) Appended to Plaintext Before Transmission Hashing with MD5, SHA1, etc. Note: There is no encryption; only hashing

36 Figure 8-16: Key-Hashed Message Authentication Codes (HMACs) Shared Key Computed HMAC Received Original Plaintext Hashing with same algorithm. Receiver Redoes the HMAC Computation On the Received Plaintext Received HMAC If computed and received HMACs are the same, The sender must know the key and so is authenticated Note that HMAC provides no nonrepudiation.

37 Figure 8-17: Kerberos Authentication System Applicant (A) Kerberos Server Key Distribution Center (K) Verifier (V) Abbreviations: A = Applicant V = Verifier K = Kerberos Server

38 Figure 8-17: Kerberos Authentication System Applicant (A) Kerberos Server Key Distribution Center (K) Verifier (V) 1. Request for Ticket-Granting Ticket 2. Response: TGT* Key nA** *TGT (Ticket-Granting Ticket) is encrypted in a way that only K can decrypt. Contains information that K will read later. **Key nA (Network Login Key for A) is encrypted with A ’ s Master Key (Key mA). In future interactions with K, A will use nA to limit the master key ’ s exposure.

39 Figure 8-18: Kerberos Ticket-Granting Service: Part 1 Applicant (A) Kerberos Server Key Distribution Center (K) Verifier (V) 1.Request Service Ticket for V; TGT; Authenticator* encrypted with Key nA 2. Response: Key AV** encrypted with Key nA; Service Ticket *Authenticator is A ’ s IP address, user name, and time stamp. This authenticator is encrypted with Key nA to prove that A sent it. **Key AV is a symmetric session key that A will use with V.

40 Figure 8-19: Kerberos Ticket-Granting Service: Part 2 Applicant (A) Kerberos Server Key Distribution Center (K) Verifier (V) *Authenticator (Auth) encrypted with Key AV. **Service Ticket contains Key AV encrypted with the Verifier ’ s master key, Key mV. 3. Request for Connection: Auth*; Service Ticket** 4. V decrypts Service Ticket; Uses Key AV to test Auth 5. Ongoing Communication with Key AV

41 Figure 8-20: Placement of Firewalls and Cryptographic Servers Dilemma  Firewalls must examine packet contents  But a growing percentage of packets are being encrypted to prevent eavesdroppers from reading them  Firewalls cannot filter encrypted packets without decrypting them

42 Figure 8-20: Placement of Firewalls and Cryptographic Servers Internet Internal Host Cryptographic Server Firewall Firewall Creates Holes for Cryptographic Systems Filtered by Firewall Not Filtered by Firewall Some firewalls pass through encrypted packets in VPNs. Cryptographic server Comes after the firewall. No filtering can be done by the firewall.

43 Figure 8-20: Placement of Firewalls and Cryptographic Servers Internet Internal Host Can Read Decrypted Packets Firewall Cryptographic Server Filtered by Firewall Open to Attack Alternatively, the cryptographic server can be placed before the firewall. The firewall can filter the decrypted packets This leaves the cryptographic server open to attack If the firewall is taken over, the hacker can read everything

44 The Market Situation SSL/TLS is becoming very popular for remote access VPN service  Works automatically for HTTP  Other applications are harder Some applications can be “ webified ”— each output output can be incorporated as a webpage For other applications, a small program can be downloaded to the client to add features Non-HTTP applications are very time consuming to manage

45 The Market Situation IPsec is Popular for Site-to-Site Networking  In tunnel mode, no need to install software on individual clients and servers  Transparent to applications