session_09_vpn__ipsec__and_tls_101908

session_09_vpn__ipsec__and_tls_101908 - VPN, IPSec and TLS...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: VPN, IPSec and TLS Cryptography and Network Security TECH 6350 Session 9 VPNs, IPsec, and TLS/SSL Manuel Mogollon m_mogollon@verizon.net Graduate School of Management Information Assurance University of Dallas 0 VPN, IPSec and TLS Session 9 – Contents • VPNs • Tunneling — IPsec — Layer 2 Tunneling Protocol (L2TP) • TLS/SSL VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 1 • VPNs and IPsec are discussed in this session, as well as TLS /SSL. 1 VPN, IPSec and TLS TCP/IP Stack and Security Related Protocols • • • • Application Layer SMTP, Telnet, FTP, Gopher Transport Layer TCP Network Layer IP • IPsec (ISAKMP) • SOCKS V5 • TLS/SSL UDP AR P S/MIME S-HTTP PGP SET RARP • IPsec (AH, ESP) • Packet Filtering • Tunneling Protocols Data Layer VPN Ethernet, Token-Ring, FDDI, X.25, Wireless, Async, ATM, SNA...Data Layer IPsec IKE v2 • PPP-EAP, IEEE 802.1X, CHAP, PAP, MS-CHAP TLS M. Mogollon – 01/08 - 2 • The IPsec (ISAKMP) key management protocol is done at the application layer of the TCP/IP stack. • The IPsec tunneling protocols, Authentication Header (AH) which it is used to authenticate and the Encapsulated Security Payload (ESP) which it is used to encrypt and to authenticate are done at the network layer of the TCP/IP stack. 2 VPN, IPSec and TLS What is a Virtual Private Network? VPNs / Private data communication channels that use a public IP network, i.e., Internet, as the basic transport for connecting corporate data centers, remote offices, mobile employees, telecommuters, customers, suppliers, and business partners. The public network is used as a wide area communications network, and it offers the appearance, functionality, and usefulness of a dedicated private network. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 3 • In RFC 2764 (Gleeson, Lin Heinanen, Armitage, & Malis, 2000), an IP based virtual private network is defined as an “emulation of a private Wide Area Network (WAN) facility using IP facilities, including the public Internet, or private IP backbones.” VPNs are used as the basic transport for connecting corporate data centers, remote offices, mobile employees, telecommuters, customers, suppliers, and business partners. The public network is used as a wide area communications network, and it offers the appearance, functionality, and usefulness of a dedicated private network. • The key point is that it is possible to conduct a private communication over a public channels by using VPNs. • One of the problems of using the Internet as a WAN is that the Internet is a public network and it doesn’t have any security. IPsec provides security services at the IP network layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. 3 VPN, IPSec and TLS E-Commerce, E-Procurement, E-Care Business Partners Mobile Workforce Headquarters Internet Suppliers Customers Telecommuters Contractors But, the Internet is a public network and it doesn’t have any security! VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 4 • There is a growing need to integrate more closely with partners, suppliers, and customers; there is also a corresponding need to “virtually” extend a company’s geographic reach to include telecommuters and mobile personnel, remote offices and sites, and major vendors and contractors. Therefore, another reason to use the Internet as the corporate WAN network is the savings in long distance charges resulting from, for example, mobile employees not having to call an 800-number to access corporate modem banks. Instead, telecommuters and the mobile force place local calls to the ISP’s POP to connect to the corporate network. • The following are some of the VPN benefits: o Ease of use – facilitates electronic communications making corporations more efficient and productive. o Lower communications cost. o Significant savings resulting from the elimination of long-haul leased lines, 800 numbers or long distance fees, modem banks, and multiple access connections. o Reduction of long distance phone call expenses with use of Voice over IP. o Savings of up to 65% on monthly circuit costs by moving from an FR and ATM environment to an IP VPN. o Lower teleworker connection costs, by as much as 20%-25% per month, over traditional dial-up & ISDN. o Use of standard protocols, IP and IPsec, which provide needed standardization. o Simplification of maintenance and support – reduces scalability issues and management complexity. 4 VPN, IPSec and TLS Secure VPNs • Security is implemented in all products that offer VPNs. • Secure VPNs are revolutionizing the way the Internet is used. • IETF has standardized IPsec (IP Security) for secure VPN applications that have the following features: — are transparent to all TCP/IP applications — can be implemented in any LAN/WAN environment using TCP/IP — can secure any business communication over the Internet. • IPsec is a mandatory part of the forthcoming IPv6 standard. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 5 • Security is the enabling technology that has revolutionized the way the Internet is used. Once people started to trust the network, new applications and services increased the user base and the commercial value of the Internet. With the right network security technology, companies could use VPNs through a public network like the Internet, or, in some cases, through a large corporate WAN. • Industry leaders are already adding security to their critical applications. • Security is included in all products that offer VPNs. This feature is being added to web browsers, operating systems, routers, email programs, etc. • Enterprises building VPNs would like to purchase products that have multiple vendor interoperability. Products that follow the standards have an advantage over non-interoperability products. • The principal applications for secure VPN technology are remote access, intranets, and extranets. • Whether its providing secure communication for employees in the field communicating by phone lines, or adding branch offices, business partners, customers, or suppliers, connected to the Internet, VPNs will allow you to set up secure, controlled communications with all these parties. 5 VPN, IPSec and TLS Implementation of VPNs • Located at the carrier’s network — In the first scenario, the service provider provides a service similar to the public switched Frame Relay or ATM service, and the customer trusts that packets will not be misdirected, modified in transit, or subjected to traffic analysis by unauthorized parties. • On the customer’s premises — In the second scenario, the customer does not trust the service provider and implements a VPN using CPE equipment that provides firewall functionality and security. • Any devices with microprocessors, such as routers, servers, firewalls or even PCs, can perform VPN functions, such as creating tunnels and encrypting packets. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 6 • When corporations use the public Internet as a backbone for their communications, there are two alternatives for VPN use: either the service provider provides a secure, managed VPN service or the customer buys the equipment and installs it on his premises. In the first scenario, the service provider provides a service similar to the public switched frame relay or ATM service, and the customer trusts that packets will not be misdirected, modified in transit, or subjected to traffic analysis by unauthorized parties. In the second scenario, the customer does not trust the service provider and implements a VPN using CPE equipment that provides firewall functionality and security. In this case, the service provider is used solely for IP packet transport. In both scenarios, security is created by connecting the two VPN endpoints by a virtual tunnel. 6 VPN, IPSec and TLS Secure VPN Business Partners Mobile Workforce Headquarters Internet Suppliers Customers Contractors Telecommuters VPNs With Secure VPNs, • I am sure to whom I am talking. • I know my message has not been modified. • I know that only authorized persons have seen my message. • I know that the message recipient can’t deny receiving my message. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 7 7 VPN, IPSec and TLS VPN Applications: Extranets and Remote Access Security Policy Server Security Policy Server Internet Server Tunnel Mode Gateway Transport Mo de Protected Subnet • Tunnel Mode • Certificate Authority Protected Subnet Mobile Workforce with IPsec Client Software Authentication is provided between a client and a corporate VPN device, or between two VPN devices. Transport Mode Authentication is provided directly between a client and a server or between two work stations. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 8 • A VPN is a private network, built on top of a public network, in which secure connections are set up dynamically between a sender and a receiver. In networks, virtual implies that connections are set up according to the organizational needs. • A VPN connection is established either by LAN to LAN or client to LAN connections. Gateway switches integrate all of the features needed (firewall, filtering, tunneling, security, bandwidth management and policy management) for high performance, reliable, and secure virtual private networking. Features may include the following: o Support for Point-to-Point Tunneling Protocol (PPTP), L2F, and IPsec with internet key exchange and X.509 Digital Certificates. o AES, DES, triple DES and RC4 encryption with MD5 and SHA hashing. o Internal or external LDAP, RADIUS, NT Domains, and token card authentication services. • The paths that the encapsulated packets follow in the Internet VPNs are called tunnels, not virtual circuits. Part of the encapsulation process performed by a tunnel endpoint includes adding a new address to the packet; this address is the one corresponding to the other endpoint of the tunnel. • Transport mode is employed between a pair of host for end-to-end security service. • Whenever either end of a security association (SA) is a security gateway the SA must be a tunnel. When the security gateway is acting as a host, then transport mode is allowed. 8 VPN, IPSec and TLS Virtual Private Networks (VPN) • Network of virtual circuits for carrying private traffic. • VPN Protocols PPP L2TP IPsec Client-server Client-server Host-to-Host Purpose Remote access via tunneling Remote access via tunneling OSI layer Layer 2 Layer 2 Intranets, extranets, remote access via tunneling Layer 3 Data Data Network IP, IPX, AppleTalk, etc IP, IPX, IP AppleTalk, etc Mode TCP/IP Layer Protocol • PPP and L2TP are aimed at remote access use. • IPsec is used for connecting LANs. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 9 • There are several types of IP tunneling mechanisms and, depending on their form, they can provide some level of intrinsic data security. IP tunneling mechanisms include IP/IP, Generic Routing Encapsulation (GRE) tunnels, Layer 2 Tunneling Protocol (L2TP), IPsec, and Multiprotocol Label Switching (MPLS). Some of these protocols are not often thought of as tunneling protocols, but they are and they do provide some type of protection. • IPsec is considered the best tunneling protocol for IP networks because it provides strong security services such as encryption, authentication, and key management. • The L2F, PPP, L2TP protocols are strictly tunneling protocols. Only IPsec can be used for encryption and key management in IP environments. IPsec is considered the best VPN solution because it includes strong security measurements, encryption, authentication, and key management. Because IPsec is designed to handle only IP packets, PPTP and L2TP are more suitable for use in non-IP multi-protocol environments such as NETBEUI, IPX, and AppleTalk. 9 VPN, IPSec and TLS VPN Benefits • Ease of use – Facilitating electronic communications makes corporations more efficient and productive. • Cost — Eliminating long-haul leased lines, 800 numbers or long distance fees, modem banks, and multiple access connections results in significant savings. — Voice over IP reduces long distance phone call expenses. — Savings of up to 65% on monthly circuit costs by moving from a FR and ATM environment to an IP VPN — Teleworker lower connection costs by 20%-25% per month over traditional dial up & ISDN. • Use of Standard Protocols – Internet Protocol IP and IPsec provide needed standardization. • Simplification of Maintenance and Support – Reducing scalability issues and management complexity simplifies network operation. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 10 • A person traveling to Paris, for example, could make phone calls from his laptop or transfer his calls to his laptop. 10 VPN, IPSec and TLS What is IPsec? IPsec / (1) A suit of security protocols standardized by the Internet Engineering Task Force (IETF) that address data privacy, integrity, authentication, and key management, as well as, tunneling to TCP/IP networks. (2) A secure architecture that supports several applications that encrypt and/or authenticate all traffic at the IP level. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 11 • IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. • IPsec can be used to protect one or more "paths" between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. The term security gateway refers to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway. • IPsec provides the following security services: data origin authentication, access control, confidentiality (encryption), connectionless integrity, rejection of replayed packets (a form of partial sequence integrity), and limited traffic flow confidentiality. 11 VPN, IPSec and TLS Why IPsec • IPsec-compliant products allow secure Virtual Private Networks in any existing IP-based network. • IPsec is based on several strong encryption standards. • IPsec provides security services such as: data origin authentication, access control, confidentiality (encryption), connectionless integrity, rejection of replayed packets (a form of partial sequence integrity), and limited traffic flow confidentiality. • IPsec has government and industry support. • IPsec allows corporations to select security services according to internal security policies. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 12 • IPsec protects traffic transparently on IP packet level. o The operation is completely transparent to the user; no changes in applications, no additional procedures or learning by the user required. • IPsec is "Native-IP”; it is not limited to e.g. operating system specific solutions. o IPsec will be everywhere IP is, unlike tunneling protocols that can typically only be found in specific operating systems,. It will also be a mandatory part of the forthcoming IPv6 standard. • IPsec has a wide variety of strong encryption standards. o Unlike previous solutions, IPsec is a standard where security has been the number one design criteria resulting in unbeatable security. • IPsec includes a secure key management solution with digital certificate support. o IPsec guarantees ease of management and use, even in large scale networks, and highly secure authentication of parties. • IPsec has the widest government and industry support, the latter including leaders in industry such as Entrust, Nortel Networks, Cisco, Microsoft, Network Associates, CheckPoint Software, TimeStep, etc. o A wide, guaranteed deployment ensures interoperability and availability of secure solutions for all needs of corporate and private users. • IPsec is not a single protocol. Instead, IPsec provides a set of security algorithms plus a general framework that allows a pair of communicating entities to use whichever algorithms provide security appropriate for the communication. 12 VPN, IPSec and TLS Internet Protocol (IP) – Security Threats • The Internet protocol has no • Attacks include: security. — Source/destination address & port — — — — IP Spoofing Packet Sniffing Session Hijacking Man-in-the-Middle IP Packet Various IP Header Fields Source IP Address Upper Protocol Destination Header (i.e., TCP, IP Address UDP, ICMP) IP Header TCP IP Header VPN Data Data Payload Data IPsec IKE v2 TLS M. Mogollon – 01/08 - 13 IP Spoofing In an IP networks is difficult to know from where the information is coming from. An intruder uses IP spoofing by impersonating another user. The intruder creates a fake message with Alice’s address as the source address and requests a connection to Bob. When Bob receives the message, he will responds with an acknowledgment and the attack starts. IP packets are easily changed, so a spoofing attack makes a packet coming from one location appear to come from somewhere else. Packet Sniffing (Electronic Eavesdropping) In most Ethernet LANs, all the packets are available to the network interface card (NIC) which listens and responds only to packets specifically addressed to that NIC. It is possible to put the NIC in the promiscuous mode - meaning that the NIC collects every packet that passes by, even if the frame doesn’t belong to the NIC. A network analyzer is a legitimate sniffer that is used by the network administrator to collect data and messages as they are transmitted on the network for later analysis. Session Hijacking (Man-in-the-Middle) In a session hijacking, rather than attempting to initiate a session via spoofing, the attacker takes over an existing connection between two computers. Most session authentication occurs only at the start of the session. Once the connection is established, the intruder determines the connection sequence numbers between the two computers, and generates traffic that appears to come from either one of the communicating parties. IP Packet IP packets can be represented in several ways, in this class we will use either on those above. 13 VPN, IPSec and TLS IPsec Interlocking Technologies Cryptographic Security Mechanisms for IP • Authentication Header (AH) — Provides integrity and authentication without confidentiality to IP datagrams. — Available even in locations where the export, import or use of encryption to provide confidentiality is regulated. • Encapsulation Security Payload (ESP) — Provides integrity, authentication, and confidentiality to IP datagrams. Key Management • Internet Key Exchange IKEv2 — Allows users to agree on authentication methods, encryption methods, keys to use, and key duration. — Key exchange could be manual or automated. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 14 • The basic key management mechanism is the Diffie-Hellman key exchange algorithm. IKEv2 supports perfect forward secrecy for keys, identity protection, authentication, user-defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms. • There are currently two ways to handle key exchange and management within IPsec’s architecture: manual and automated keying. Both of these methods are mandatory requirements of IPsec. 14 VPN, IPSec and TLS IP Security Architecture • — — — • • Encapsulation Security Payload Protocol AH is used to authenticate. ESP is used to encrypt and to authenticate. Algorithms for encryption and authentication — — Symmetric encryption algorithms. Keyed hash algorithms. Encryption Algorithm Key Management Protocols — IPsec Databases (SPD, SAD, PAD) ESP/AH Engine Information shared between two Gateways on how to secure communications. Security Protocols — — • Security Policy Database (SPD) Security Association Database (SAD) Peer Authorization Database (PAD) Security Associations — • IP Packets IPsec Databases Authentication & Integrity Algorithms Key Management Manual and Automated VPN Authentication Header Protocol IPsec IKE v2 TLS M. Mogollon – 01/08 - 15 • IPsec Databases o Security Policy Database (SPD) o Security Association Database (SAD) o Peer Authorization Database (PAD) • Security Associations o Information shared between 2 Gateways on how to secure a communication. • SAs has three parameters: o Security Parameter Index (SPI) o IP Destination Address o Security Protocol ID, which identifies whether the SA is AH or ESP. • Security Protocols o IP Authentication Header (AH) is used to authenticate. o IP Encapsulated Security Payload (ESP) is used to encrypt and to authenticate. • Cryptographic Algorithms for Authentication and Encryption. o RFC 4305 defines the mandatory, default algorithm for use with AH and ESP and a similar document. RFC 4307 defines the mandatory algorithm for use with IKEv2. Each cryptographic algorithm has a separate RFC. o AES, Triple DES, and other symmetric encryption algorithms are used to encrypt the data. Keyed hash algorithms are used for authentication and integrity. • Key Management Protocols o The key management protocols are described in the Internet Key Exchange (IKEv2), RFC 4306. 15 VPN, IPSec and TLS Security Protocols • IPsec provides mechanisms to provide security services to IP and upper layer protocols (e.g., UDP or TCP). • IPsec protect IP datagrams by defining a method in a SA. • The SA associated with a connection could be Encapsulating Security Payload (ESP), or Authentication Header (AH), but not both. • If both AH and ESP protection are applied to a connection, then two (or more) SAs are created to provide protection to the connection. • To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required. • Both ESP and AH security protocols support two modes of operation: transport or tunnel mode. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 16 • IPsec provides mechanisms to provide security services to IP and upper layer protocols (e.g., UDP or TCP). IPsec protects IP datagrams by defining a security protocol in an SA. The SA associated with a connection could be Encapsulating Security Payload (ESP), or Authentication Header (AH), but not both. If both AH and ESP protection are applied to a connection, then two (or more) SAs are created to provide protection to the connection. To secure typical, bidirectional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required. Both ESP and AH security protocols support two modes of operation: transport or tunnel mode. • The IP Authentication Header (AH) provides connectionless integrity, data origin authentication, and an optional anti-replay service. The Encapsulating Security Payload (ESP) protocol may provide confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols. 16 VPN, IPSec and TLS IPsec Negotiation Applications IPsec Databases (SAD, PAD) 5 Applications Negotiator Engine Negotiator Engine IPsec Databases (SAD, PAD) 1 6 4 TCP/IP SA Attributes TCP/IP 2 3 Security Policy Database UnprotectProtect Engine 2 SPI UnprotectProtect Engine Security Policy Database 1 Outbound IPsec Packet VPN Inbound IPsec Packet IPsec IKE v2 TLS M. Mogollon – 01/08 - 17 Outbound Packet 1. The application calls the TCP/IP stack. 2. The TCP/IP packet is captured by the unprotected-protected engine. 3. After checking it out in the Security Policy Database (SPD), the Unprotected-Protected Engine determines whether traffic going to a specific address needs to be protected or allowed to bypass IPsec. In general, packets are selected for one of three processing modes based on IP address and transport layer header information matched against entries in the database (SPD). Each packet is either protected using IPsec services, discarded, or allowed to bypass IPsec protection. 4. If the packet needs to be protected, the Unprotected-Protected Engine passes the address on to the Negotiator who checks the address in the Security Association (SA) and the Security Parameter Index (SPI). 5. The negotiator engine looks up the SA and SPI in its internal database. If an SA has not been negotiated for that specific address, then the Negotiator triggers the creation of an SA by initiating an IKE negotiation with the peer address. 6. Once that negotiation is complete, the SPI and SA are passed to the Unprotected-Protected Engine. Now all packets sent to that address are protected by the Protected Engine with keys negotiated by the Negotiator. Inbound Packet 1. If the incoming packet comes in to the port reserved for the IKE negotiation (port 500 or 4500), and no SA has been negotiated with the incoming address, then the Unprotected-Protected Engine will pass all of the IKE packets on to the Negotiator. 2. If the arriving packet has an SPI (Security Parameter Index) associated with it, the SA (Security Association) associated with that SPI is retrieved from the IPsec databases. If the SPI is not in the database, then the packet can be rejected. 3. If the arriving packet does not have an SPI embedded in it, the unprotected-protected Engine can presume that the packet doesn’t have an SA associated with it. Since there is no SA associated with the packet, it can be rejected. 17 VPN, IPSec and TLS IPsec Document Roadmap IP Security Architecture RFC 4301 AH Protocol RFC 4302 ESP Protocol RFC 4303 IKE v2 RFC 4306 Encryption Algorithms RPC 3602 (AES-CBC (128-Bit) RFC 3686 (AES-CTR) RFC 2451 (Triple DES-CBC) Authentication Algorithms RFC 3566 (AES-XCBC-MAC-96) RFC 2404 (HMAC-SHA1-96) RFC 2403 (HMAC-MD5-96) Key Management RFC 4120 (Kerberos) RFC 2093 (GKMP) RFC 2412 (OAKLEY) VPN • • • • • • • • • • • • • • • • • • • • • • • IPsec IKE v2 TLS M. Mogollon – 01/08 - 18 RFC 1828, IP Authentication using Keyed MD5, P. Metzger & W. Simpson, August 1995. RFC 1829, The ESP DES-CBC Transform, P. Karn, P. Metzger & W. Simpson, August 1995. RFC 1851, The ESP Triple DES Transform, P. Karn, P. Metzger & W. Simpson, September 1995. RFC 2104, HMAC: Keyed-Hashing for Message Authentication, H. Krawczyk, M. Bellare & R. Canetti, February 1997. RFC 2144, The CAST-128 Encryption Algorithm, C. Adams, May 1997. RFC 2286, Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128, J. Kapp, February 1998. RFC 2403, The Use of HMAC-MD5-96 within ESP and AH, C. Madson & R. Glenn, November 1998. RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH, C. Madson & R. Glenn, November 1998. RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV, C. Madson & N. Doraswamy, November 1998. RFC 2411, IP Security Document Roadmap, R. Thayer, N. Doraswamy & R. Glenn, November 1998. RFC 2412, The OAKLEY Key Determination Protocol, H. Orman, November 1998. RFC 2451, The ESP CBC-Mode Cipher Algorithms, R. Pereira & R. Adams. November 1998. RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec. S. Frankel. September 2003. RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec. S. Frankel, R. Glenn, S. Kelly. September 2003. RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). R. Housley. January 2004 RFC 4120, The Kerberos Network Authentication Service (V5). C. Neuman. July 2005. RFC 4301, Security Architecture for the Internet Protocol. S. Kent, K. Seo. December 2005. RFC 4302, IP Authentication Header. S. Kent. December 2005. RFC 4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005. RFC 4305, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. Eastlake 3rd. December 2005. RFC 4306, Internet Key Exchange (IKEv2) Protocol. C. Kaufman. December 2005 RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). J. Schiller. December 2005 RFC 4308, Cryptographic Suites for IPsec. P. Hoffman. December 2005. 18 VPN, IPSec and TLS Authentication Header (AH) • • • Authentication Data Algorithms • HMAC-SHA-1-96 (Must be supported) • AES-XCBC-MAC-96 (Should be supported) • HMAC-MD5-96 (May be supported) Data Integrity: Undetected modification to a packet’s content in transit is not possible Authentication: Enables a network device to authenticate a user. Anti-replay service (optional) Authentication IP Header Payload Data 8 bits 8 bits Word 1 AH 16 bits Next Header AH Payload Length Reserved Word 2 Security Parameters Index (SPI) Word 3 Sequence Number Word 4 - Integrity Check Value –ICV (variable) 32 bits VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 19 • The AH protocol, RFC 4302, defines the format for IPsec packets that require data origin authentication, connectionless integrity, and anti-replay services only. The AH does not encrypt the data portion of the packet. AH may be applied alone, in combination with ESP, or in a nested fashion through the use of tunnel mode. A description of each of the different fields is given below. • Next Header: Identifies the type of header of the next payload after the Authentication Header. • Payload Length: Specifies the length of AH in 32-bit words (4-byte units), minus "2". • Reserved: This 16-bit field is reserved for future use. • Security Parameters Index (SPI): The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for the datagram. The SPI tells which security protocols are being used. The algorithms and keys are included in this field. • Sequence Number: This field contains a monotonically increasing counter value (sequence number) that tells how many packets have been sent and provides anti-replay protection. The sender's counter and the receiver's counter are initialized to 0 when an SA is established. The first packet sent using a given SA will have a Sequence Number of 1. • Integrity Check Value: This variable-length field contains the Integrity Check Value (ICV) for the packet. The field must be an integral multiple of 32 bits in length. The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (HMACs) based on symmetric encryption algorithms (e.g., AES) or on one-way hash functions (e.g., MD5 or SHA1). • The mandatory-to-implement authentication algorithms are: HMAC-SHA-1-96; AES-XCBCMAC-96; HMAC-MD5-96. 19 VPN, IPSec and TLS Encapsulation Security Payload (ESP) • • • Data Integrity + Authentication (optional) Anti-replay Service (optional) Confidentiality (optional) Authentication Encryption Original IP Header ESP Header Payload Data ESP Trailer ESP ICV Security Parameters Index (SPI) Sequence Number Payload Data (variable) Padding (0 – 255 bytes) Pad Length Next Header Integrity Check Value –ICV (variable) 8 bits 8 bits 32 bits VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 20 • RFC 4303, “ESP Protocol,” provides the same security services that AH provides (data origin authentication, connectionless integrity, and anti-replay service); it also provides traffic flow confidentiality (encryption). The primary difference between the authentication provided by ESP and the authentication provided by AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). The set of services provided by ESP depends on options selected at the time that the security association is established and on the placement of the implementation. • The ESP handles encryption of IP at the packet level using symmetric key encryption. ESP is designed to use any number of encryption algorithms.. The mandatory-to-implement encryption algorithms are Triple DES-CBC, AES-CBC (128-Bit), and AES-CTR. Other algorithms, however, such as RC5, IDEA, Three-key triple IDEA, Cast, and Blowfish, could be used because the Domain of Interpretation (DOI) has assigned identifiers to them. • The ESP header is inserted between the IP header and the rest of the packet. • The SPI and Sequence number field provide the same functions as they do in the AH. • The TCP portion and Data (Payload), and ESP trailer are all encrypted. • ESP provides authentication in the same manner as the AH does. 20 VPN, IPSec and TLS AH and ESP Modes of Operation Tunnel Transport Server Client VPN Device VPN Device AH Inner IP Header Outer IP Header Tunnel Mode New IP Header ESP Header Original AH IP Header Outer IP Header Payload Data New IP Header Confidentiality Header ESP Inner IP Header Inner IP Header Original Header IP Header AH Payload Data IPsec Confidentiality Original Header IP Header ESP Payload Data Authentication / Integrity Authentication / Integrity VPN Payload Data Authentication / Integrity Authentication / Integrity Transport Mode Original IP Header IKE v2 TLS M. Mogollon – 01/08 - 21 • AH and ESP support two modes of operation: the transport mode and the tunnel mode. A transport mode SA is a security association between two hosts. When a security gateway works in transport mode, it acts as a host: the traffic is destined for itself. A tunnel mode SA is a security association between a host and a gateway or between two gateways. • Transport mode is used to protect upper-layer protocols. Tunnel mode is used to protect entire IP packets, meaning that the entire IP packet is encapsulated in another IP packet, and a new IP header is inserted between the outer and inner IP headers. • In a transport mode, the security protocol header appears immediately after the Original IP header and before Payload Data (any higher layer protocols, e.g., TCP or UDP and Data). In ESP transport mode, SA provides security services only for the higher layer protocols, not for the Original IP Header or any extension headers preceding the ESP header. In the case of AH, the protection is extended to the Original IP Header. • For a tunnel mode SA, an “outer” header specifies the IPsec end-point and processing destination, plus an "inner" header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packets, i.e., all of the inner IP header is protected, as well as higher layer protocols. If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header. 21 VPN, IPSec and TLS Internet Key Exchange (IKE v2) • IPsec security services use symmetric encryption. — Source and destination need to agree to the mechanisms used to share the secret keys and the keys that are used for authentication/integrity and encryption services. • IPsec supports both manual and automatic distribution of keys. • Public Key is used for automatic key management, but other automated key distribution techniques may be used. • IKE v2 defines procedures and packet formats to establish, negotiate, modify, and delete Security Associations (SA). VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 22 • Because IPsec security services use symmetric encryption, it is necessary for both hosts, source and destination, to agree to the mechanisms used to share the secret keys, as well as to the keys that are used for authentication/integrity and encryption services. IPsec supports both manual and automatic distribution of keys. Public key is used for automatic key management, but other automated key distribution techniques may be used. • RFC 4306, IKE v2 (Hoffman, 2005), combines the security concepts of authentication, key management, and security associations to establish the required security for government, commercial, and private communications on the Internet. It does so by defining procedures and packet formats to establish, negotiate, modify, and delete security associations (SA). IKE v2 defines payloads for exchanging key generation and authentication data, thus providing a consistent framework for transferring key and authentication data independent of the key generation technique, encryption algorithm, and authentication mechanism. • A security association (SA) payload indicates a proposal for a set of IPsec encryption algorithms, authentication mechanisms, and key establishment algorithms to be used in IKE, as well as for ESP and/or AH. IKE v2 is not bound to any specific cryptographic algorithm, key generation technique, or security mechanism; the independence from specific security mechanisms and algorithms provides a forward migration path to better mechanisms and algorithms. When improved security mechanisms are developed to counter new attacks against current encryption algorithms, authentication mechanisms and key exchanges would be created; in those situations, IKE v2 would allow the updating of the algorithms and mechanisms without having to develop a completely new IKE or to patch the current one. 22 VPN, IPSec and TLS Negotiating a Security Association using IKE IKE Security Association (IKE SA) proposes the following: • Type of protection to use, either ESP or AH. • Authentication algorithms and keys for signing data. • Encryption algorithms and keys to protect data. • Hash algorithms to reduce data for signing. • Information about a group over which to do a DiffieHellman exchange. • A pseudo-random function (prf) to hash certain values during the key exchange. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 23 • A security association normally includes the parameters listed below, but might include additional parameters as well: o Type of protection used, either ESP or AH. o Authentication algorithm used with AH. o Key(s) used with the authentication algorithm in AH. o Encryption algorithm and mode used with ESP. o Key(s) used with the encryption algorithm in ESP. o Initialization vector for the encryption algorithm used in ESP. o Authentication algorithm and mode used with the ESP transform. o Authentication key(s) used with the authentication algorithm in ESP o Lifetime of the key used or time when key change should occur. o Hash algorithms to reduce data for signing used. o Information provided about a group over which to do a Diffie-Hellman exchange. o Lifetime of the security association established. o Source address(es) of the security association provided. 23 VPN, IPSec and TLS Security Association I would like to establish a secure IP communication, and since we haven’t talked before, let’s agree on all the security parameters we need by creating an SA. Source Once we finish, let’s assign an index to the SA, (Security Parameter Index) and store the information in our Security Policy Databases. By doing this, we will not have to create another SA when we communicate again. Destination Security Parameters • Encryption and authentication algorithms — Encapsulation Security Payload (ESP) — Authentication Header (AH) • • • • • • VPN Crypto keys Initialization values Protocol mode Source and destination IP addresses Source and destination IDs Key lifetimes IPsec IKE v2 TLS M. Mogollon – 01/08 - 24 • A Security Association (SA) is a proposal for a set of IPsec encryption algorithms, authentication mechanisms, and key establishment algorithms to be used in IKE, as well as for ESP and/or AH. • IKE v2 is not bound to any specific cryptographic algorithm, key generation technique, or security mechanism; the independence from specific security mechanisms and algorithms provides a forward migration path to better mechanisms and algorithms. When improved security mechanisms are developed to counter new attacks against current encryption algorithms, authentication mechanisms and key exchanges are created, IKE v2 will allow the updating of the algorithms and mechanisms without having to develop a completely new IKE or patch the current one. • IKEv2 Algorithm Selection – • The following features are used by IKE and must be negotiated for the IPsec security association: • Encryption algorithm to protect data: Must implement 3DES and should implement AES-CBC128 and AES-CTR-128 modes. • Integrity protection algorithms to produce a fingerprint of the data: Must implement HMACSHA1-96, should implement AES-XCBC-96, and may implement HMAC-MD5-96. • Information about which Diffie-Hellman Modular Exponentiation Group (MODP) to use: Must implement D-H MODP Group 2 (discrete log 1024 bits), should support D-H Group 14 (2048), and may support D-H elliptic curves over GF [2155] and over GF [2185]. • Pseudorandom function to use: Must implement PRF-HMAC-SHA1 (RFC2104), should support PRF-AES-XCBC-PRF-128 (RFC 3664), and may implement PRF-HMAC-MD5 (RFC 2104). 24 VPN, IPSec and TLS Internet Key Exchange (IKE) • First Message Exchange — IKE Security Association – In IKE_SA_INIT, the initiator and responder negotiate the use of encryption algorithms by establishing an IKE_SA. The agreed keys are used to protect the IKE_AUTH exchange. – In IKE_AUTH, the initiator and responder authenticate each other using authentication mechanisms such as digital signatures (exchanging certificates), Extensible Authentication Protocol (EAP), or pre-shared keys. — Child Security Association – In IKE_AUTH, the first IKE_SA and associated IPsec SA, called child SA, are created. • Second Message Exchange — CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to rekey IKE_SAs and CHILD_SAs. — All messages are cryptographically protected using the encryption algorithms and keys negotiated in IKE_SA_INIT and IKE_SA_AUTH. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 25 • First Message Exchange o In IKE_SA_INIT, the initiator and responder negotiate the use of encryption algorithms by establishing an IKE_SA and then by exchanging information for key agreement by sending nonces and Diffie-Hellman values. The agreed keys are used to protect the IKE_AUTH exchange. At his point, the initiator and the responder have agreed on cryptographic keys algorithms, but without authenticating each other. o In IKE_AUTH, the initiator and responder authenticate each other using authentication mechanisms such as digital signatures (exchanging certificates), Extensible Authentication Protocol (EAP), or pre-shared keys. In IKE_AUTH, the first IKE_SA and associated IPsec SA, called child SA, are created. • Second Message Exchange o The second message exchange consists of a single request/response, which may be initiated by either end, so, in this section, the term “Initiator,” refers to the end point initiating this exchange. The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to rekey IKE_SAs and CHILD_SAs. All messages are cryptographically protected using the encryption algorithms and keys negotiated in IKE_SA_INIT and IKE_SA_AUTH. However, to enable stronger guarantees of forward secrecy for the key generated for IKE_SA and for CHILD-SA, the CREATE_CHILD_SA request can use additional DiffieHellman exchanges to create new keys. 25 VPN, IPSec and TLS IKE First Message Exchange I would like to establish an IKE security association and a child security association. Initiator Responder Networking Device with IPsec Networking Device with IPsec End -system or Gateway environment End -system or Gateway environment 1 Ni KEi SAi1 HDR 2 SK{IDi, [CERT], [CERTREQ], [IDr], AUTH, SAi2, TSi, TSr} HDR HDR SAr1 KEr Nr [CERTREQ] 3 4 HDR SK{IDr, [CERT], AUTH, SAr2, TSi, TSr} AUTH – Authentication CERT – Certificate CERTREQ – Certificate Request HDR – IKE Header i, r – Initiator, Responder IDi - Initiator Identification KEr – Responder DH gi IDr – Responder Identification KEi – Initiator DH gi Ni, Nr – Nonce SA - Security Association TSi, TSr – Traffic Selector SAi1 , SAr1 – Used to create IKE_SA SAi2, SAr2 – Used to create the first CHILD_SA SK{….} – Payload is encrypted and integrity protected using SK_e and SK_a. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 26 • In step 1, the Initiator sends an HDR that contains the Security Parameter Index (SPI), the IKE version number, and some message identifiers. These message identifiers include SAi1, which indicates the cryptographic algorithms the initiator supports for the IKE_SA and the proposed Diffie-Hellman Group. The other message identifiers are the KEi payload, which includes the initiator’s Diffie-Hellman value, gi and modulo p. The initiator’s nonce (Ni) is used to protect against replay attacks. The header (HDR) identifies the initiator’s Security Parameter Index (i.e., the initiator’s reference for the IKE_SA to be established), the IKE version number, flags specific to the message, and a message identifier that is used for retransmissions and matching responses to requests. The SAi1 payload includes the supported cryptographic algorithms for the IKE_SA. The SAi1 payload identifies at least one proposal that contains algorithms for encryption, the pseudorandom function, and integrity, and the proposed Diffie-Hellman group. • In step 2, the Responder sends an HDR, which contains the initiators’ Security Parameter Index, the IKE version number, and the same message identifiers used by the initiator. The Responder chooses a cryptographic suite by mixing-and-matching the initiator’s offered suites and expresses that choice to the Initiator in SAr1. The Responder also completes the Diffie-Hellman exchange with the KEr, gr and sends its nonce in Nr, and may optionally request a specific type of certificate, for example, X.509, by sending the request in [CERTREQ]. No identities are disclosed in the IKE_SA_INIT exchange, other than the IP addresses in the IP headers. • At this point, Initiator and Responder have negotiated a shared but unauthenticated IKE_SA (SAr1). Also, after the Diffie-Hellman key exchange, each party generates a shared but unauthenticated key, SKEYSEED, from which all keys are derived for that IKE_SA. The keys generated from SKEYSEED are known as the following: SK_e (encryption), and SK_a (message authentication, integrity); SK_d for deriving keys for child SAs; and SK_p for creating AUTH payload in the second request/response exchange. Note that separate SK_e and SK_a keys are generated for each direction. 26 VPN, IPSec and TLS IKE Second Message Exchange I would like to generate a new Child_SA or rekey IKE SA and/or a previous Child_SA. Initiator Responder Networking Device with IPsec Networking Device with IPsec End -system or Gateway environment End -system or Gateway environment SK{ [N+], SA, Ni, [KEi], TSi, TSr} HDR 5 6 HDR SK{ [N+], SA, Nr, [KEr], TSi, TSr} HDR – IKE Header i, r – Initiator, Responder [KE] – Optional Key Exchange [N+] – Optional Notify Ni, Nr – Nonce SA - Security Association TSi, TSr – Traffic Selector SK{….} – Payload is encrypted and integrity protected using SK_e and SK_a. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 27 • The second message exchange consists of a single request/response, which may be initiated by either end, so, in this section, the term Initiator, refers to the end point initiating this exchange. The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to rekey IKE_SAs and CHILD_SAs. All messages are cryptographically protected using the encryption algorithms and keys negotiated in IKE_SA_INIT and IKE_SA_AUTH. However, to enable stronger guarantees of forward secrecy for the key generated for IKE_SA and for CHILD-SA, the CREATE_CHILD_SA request can use additional Diffie-Hellman exchanges to create new keys. • In CREATE_CHILD_SA, step 5, the Initiator sends the header (HDR), which includes the Initiator’s and the Responder’s Security Parameter Indexes, the IKE version number, and the message identifiers. The notation SK {….} indicates that the payload is encrypted and integrity protected using SK_e and SK_a. The Initiator (a) sends Notify, [N+], which contains additional details for the CHILD_SA (optional step); (b) proposes an SA; (c) sends a nonce in Ni payload; (d) sends a new Diffie-Hellman value, gi, in Kei payload (optional step; and (e) sends the traffic selectors TSi and TSr. The whole message is encrypted and integrity protected using keys computed from SK_d. • In the CREATE_CHILS_SA response, step 6, the responder sends the header (HDR) which includes the Initiator’s and Responder’s Security Parameter Indexes, the IKE version number, and the message identifier. The Responder (a) sends Notify, [N+], which contains additional details for the CHILD_SA (optional step); (b) agrees to the proposed algorithms in an SA payload; (c) sends its nonce in Nr payload; (d) sends a new Diffie-Hellman value, gr, in Kei payload (optional step); and (e) sends the traffic selectors TSi and TSr. The whole message is encrypted and integrity protected using keys computed from SK_d. 27 VPN, IPSec and TLS IKE v2 Header IKE_SA Initiator’s Security Parameters Index (SPI) IKE_SA Responder’s Security Parameter Index (SPI) Next Payload MjVer MjVer Exchange Type Flags Message ID Length • • Initiator’s SPI (8 Octets) – A value selected by the initiator to identify a unique IKE security association. • • • • Next Payload (1 Octet) – the type of payload that follows the header. • • Flags (1 Octet) – Indicates specific options that are set for the message. • Length (4 Octets) – Length of total message (header and payload) Responder’s SPI (8 Octets) – A value selected by the responder initiator to identify a unique IKE security association. This value is zero in the first message of the IKE_INIT. Major Version (4 bits) – The major version of the IKE protocol used. Minor Version (4 bits) – The minor version of the IKE protocol used. Exchange Type (1 Octet) – The type of exchange being use, IKE_INIT, IKE_AUTH, CREATE_CHILD_SA, or INFORMATIONAL. Message ID (4 Octets) – Message identifier used to control retransmision of lost packets. It is used to prevent message replay attacks. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 28 28 VPN, IPSec and TLS Generating Key Material in IKE_SA • In IKEv2, Diffie-Hellman is the only key exchange algorithm used. • Key material for all of the cryptographic algorithms used in both IKE_SA and CHILD_SA is always derived as the output of a prf algorithm. • Diffie-Hellman exchange has the following three components: a generator g, the modulo p, and a secret that in IKEv2 terminology is called i or r. • During IKE_INIT, in KEi and KEr, the Initiator and Responder exchange Diffie-Hellman information, gi and gr, as well as nonces Ni and Nr • The shared key, SKEYSEED, is calculated by both the Initiator and Responder from the nonces exchanged and the Diffie-Hellman shared secret key generated, gi and gr, according to the following formula: SKEYSEED = prf ( Ni | Nr , g ir ) VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 29 • In IKE_SA, four cryptographic algorithms are negotiated: encryption algorithms, integrity protection algorithms, a Diffie-Hellman group, and a pseudo random function (prf). Key material for all of the cryptographic algorithms used in both IKE_SA and CHILD_SA is always derived as the output of a prf algorithm. In IKEv2, Diffie-Hellman is the only key exchange algorithm used. • The Diffie-Hellman exchange has the following three components: a generator g, the modulo p, and a secret that in IKEv2 terminology is called i or r. During IKE_INIT, the Initiator and Responder exchange Diffie-Hellman information in KEi and KEr. That information includes gii and gr, as well as nonces Ni and Nr. • The shared key, SKEYSEED, is calculated by both the Initiator and Responder from the nonces exchanged and the Diffie-Hellman shared secret key generated, gi and gr, according to the following formula: SKEYSEED = prf ( Ni | Nr , g ir ) 29 VPN, IPSec and TLS IKE v2 DH Key Agreement In the security association, the initiator and responder agreed on the same group or pair of g and p. Initiator g =12 p = 47 I Secret = i = 3 Nonce = Ni = 11 g i = 12 3 (mod 47) = 36 g and p do not need to be secret 36, 11 14, 7 Responder g = 12 p = 47 R Secret = r =5 Nonce = Nr = 7 g r = 12 5 (mod 47) = 14 g i r = 36 5 (mod 47) = 18 g i r = 14 3 (mod 47) = 18 18 18 Both ends use 11, 7, and 18, as the secret and seed to calculate SKEYSEED SKEYSEED = prf ( Ni | Nr , g ir ) SKEYSEED = prf ( secret, seed ) VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 30 • This slide uses the same example used to describe Diffie-Hellman, the different is how the values are named in IKEv2. • Whenever a key exchange is established, the initiator and the responder agree on the corresponding p and g numbers by selecting a Diffie-Hellman group. • Then, they exchange not only their public keys, gi and gr, but also their nonces. • The nonces are not used to calculated the agreed key, in this case 18, but to calculate the SKEYSEED using a pseudo random function. 30 VPN, IPSec and TLS Diffie-Hellman Groups in IKE • Three distinct group representations can be used with IKE. — Modular Exponentiation Groups (named MODP) — Elliptic Curve Groups over the field GF [2n] (named EC2N) — Elliptic Curve Groups over GF [P] (named ECP). • Groups Identifiers supported in IKE — — — — — — — — — — Group 0: Group 1: Group 2: Group 4: Group 5: Group 14: Group 15 Group 16 Group 17 Group 18 VPN No group (used as a placeholder and for non-DH exchanges) A modular exponentiation group with a 768 bit modulus A modular exponentiation group with a 1024 bit modulus An elliptic curve group over GF [2^155] A modular exponentiation group with a 1536 bit modulus A modular exponentiation group with a 2048 bit modulus A modular exponentiation group with a 3072 bit modulus. A modular exponentiation group with a 4096 bit modulus. A modular exponentiation group with a 6144 bit modulus. A modular exponentiation group with a 8192 bit modulus. IPsec IKE v2 TLS M. Mogollon – 01/08 - 31 • In IPsec and IKEv2, the groups are predetermined and the initiator and responder agree to one of the nine groups during the Security Association. • In IPSec IKE (Internet Key Exchange), for example the Group 2 is used to identify a 1024 bit modulus. • If the Group is 2, then the receiving unit knows that g=2 p = 21536 – 21472 - 1 + 264 * { [21406 pi] + 741804 }. p= 1797693134862315907708391567937874531978602960487560117064444236841971802161585193 6894783379586492554150218056548598050364644054819923910005079287700335581663922955 3136239076508735759914822574862575007425302077447712589550957937778424442426617334 727629299387668709205606050270810842907692932019128194467627007 It has been rigorously verified that p is a prime. 31 VPN, IPSec and TLS TLS and SSL • TLS and SSL protocols are used to secure the communication between a client (Web browser) and a server (Web Server) over the Internet. • TLS versions 1.1, 1.0, and SSL 3.1 and 3.0 are very similar. TLS and SSL clients are built into all web browsers. • TLS and SSL provide mutual authentication (digital signature), confidentiality (data encryption), and data integrity (hash algorithms). • A secure client-server communication requires: — Which protocol and version (TLS 1.0, 1,1, SSL2 or SSL3) to use and which cryptographic algorithm will be used. — Whether or not to authenticate each other. Server and client authentication. — The type of cryptographic key exchange where both parties agree on a pre-master secret key — The creation of session keys to encipher the message. — The encryption technique to the enciphering of data using keys generated from the premaster key. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 32 • The TLS and SSL protocols are used to secure a client-server communication over the Internet, and they negotiate and provide the essential functions of a secure transaction: mutual authentication, data encryption, and data integrity. There are two SSL versions: SSL 2.0 supports server authentication only; SSL 3.1 supports both client and server authentication. TLS 1.0 and 1.1 support both client and server authentication. • TLS and SSL allow users to define the level of security that best meets their needs. Both are industry standards and are used in millions of Internet transactions. Users can select RC4, DES, 3DES, or AES for encryption and, for authentication, they can select RADIUS (username and password), RSA SecurID (username and token + pin), or X.509 digital certificates. • A secure client-server communication requires server and client authentication, a cryptographic key exchange where both parties agree on a pre-master secret key, and the enciphering of data using keys generated from the pre-master key. When a client and a server agree to communicate using the TLS or SSL protocol, they also need to agree on several other key points: (1) Which protocol and version (TLS 1.0, 1.1, SSL2 or SSL3) to use, as well as which cryptographic algorithm; (2) Whether or not to authenticate each other; (3) That certain public-key encryption techniques will be used to generate a pre-master secret key; and (4) That session keys will be created to encipher the message. These processes are performed in the TLS or SSL Handshake Protocol. • In all TLS and SSL handshakes, the client will authenticate and verify the identity of the server using digital certificates. The server can also request that the client sends a client digital certificate (optional). An important advantage of TLS and SSL is their ability to negotiate unique encryption keys • In any TLS or SSL session, a client and a server are able to negotiate unique enciphering keys even if they have not previously communicated with each other. 32 VPN, IPSec and TLS TCP/IP Stack and Security Related Protocols Application Layer SMTP, Telnet, FTP, Gopher Transport Layer TCP Network Layer Data Layer VPN IP RARP Ethernet, Token-Ring, FDDI, X.25, Wireless, Async, ATM, SNA...Data Layer IPsec S/MIME S-HTTP PGP IPsec (ISAKMP) • SOCKS V5 • TLS/SSL UDP ARP • • • • IKE v2 • IPsec (AH, ESP) • Packet Filtering • Tunneling Protocols • PPP-EAP, IEEE 802.1X, CHAP, PAP, MS-CHAP TLS M. Mogollon – 01/08 - 33 • The TLS and SSL protocols are implemented at the transport layer of the TCP/IP stack. 33 VPN, IPSec and TLS TLS Architecture • Session — A TLS session is an association between a client and a server. Sessions are created by the Handshake Protocol. — Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. — Sessions are used to avoid the negotiation of new security parameters for each connection. • Connection — A connection is a transport (in the OSI layering model definition) that provides a suitable type of service. — For TLS, such connections are peer-to-peer relationships. — A connections is transient. Every connection is associated with one session. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 34 • In SSL, a session is first established between a client and a server and, then, a connection is established. 34 VPN, IPSec and TLS Session Parameters • Session identifier — An arbitrary byte sequence chosen by the server to identify an active or resumable session state. • Peer certificate — An X509.v3 certificate of the peer. This element of the state may be null. • Compression method — The algorithm used to compress data prior to encryption. • Cipher spec — Specifies the data symmetric encryption algorithm (such as null, DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also defines cryptographic attributes such as the hash_size. • Master secret — A 48-byte secret shared between the client and server. • Is Resumable — A flag indicating whether the session can be used to initiate new connections. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 35 35 VPN, IPSec and TLS Connection Parameters • Server and client random — Byte sequences that are chosen by the server and client for each connection. • Server write MAC secret — The secret key used in MAC operations on data written by the server. • Client write MAC secret — The secret key used in MAC operations on data written by the client. • Server write key — The symmetric cipher key used by the server to encipher data and by the client to decipher it. • Client write key — The symmetric cipher key used by the client to encipher data and by the server to decipher it. • Initialization vectors — When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key. • Sequence numbers — Sequence numbers maintained by each party for transmitted and received messages. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 36 36 VPN, IPSec and TLS TLS Record Protocol • The TLS Record Protocol provides connection security that has the following four basic properties: — The connection is private. Symmetric encryption (e.g., AES, DES, RC4, etc.) is used for data encryption, after an initial handshake in which a pre-master secret key is defined. — The negotiation of a shared secret is secure. – No attacker can modify the negotiation communication without being detected by the parties to the communication. — The peer's identity can be authenticated using asymmetric or public key cryptography (e.g., RSA, DSS, etc.). — The connection is reliable. – Message transport includes a message integrity check using a keyed MAC (HMAC). – HMAC can be used with a variety of different hash algorithms, but TLS uses MD5 and SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, data). VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 37 37 VPN, IPSec and TLS TLS Record Protocol The Record Protocol is responsible for coordinating the client and server sessions. Message Block Mn M1 M2 … Mn Key Exchange .. Key Blocks of equal size such that the final SSL Record is not bigger than 214 bytes. Compressed Cleartext Message Compression (Optional) SSL Header Stream Cipher HMAC Block Cipher Padding Enciphered [Compressed Cleartex Message ║ HMAC] HMAC HMAC-SHA-1 HMAC-RSA Key Key Exchange Data Encryption Stream Ciphers: RC4 40-bit or 128-bit key. Block Ciphers: DES 56-bit, 3DES 168-bit, or AES-128 VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 38 • First, the client message is divided into message blocks that have arbitrary length but no more than 214 bytes, then compression is applied (optional), and, finally, a message authentication code (MAC) is computed. The compressed cleartext and the MAC are appended and enciphered using symmetric encryption, either stream ciphers or block ciphers. If a block cipher is used, some padding is required so the total data size, compressed message plus MAC plus padding, is a multiple of the cipher’s block. • Enciphering the Data: TLS supports data encryption with one of the following symmetric encryption algorithms: RC4 using 128-bit, DES using 56-bit, 3DES using 168-bit, and AES using 128-bit and 256-bit. Most TLS solutions typically negotiate encryption strength downward to the level supported by the lowest end of the connection. • Public Key: Depending on the certificate authority, the key size of the public-key / private-key pair may be different. VeriSign uses either 512 bits or 1024 bits, depending on the server software. The VeriSign private key, used to sign certificates, is 1024 bits, and the session key used in the TLS transaction is the strongest permitted by US Government law (generally either 128 bit or 256 bits). • There are four record protocols: the Handshake Protocol, the Alert Protocol, the Change Cipher Spec Protocol, and the Application Data Protocol. 38 VPN, IPSec and TLS Handshake Protocol (Session State) Phase 1 Establishing Security Capabilities Client_Hello Client Exchange client and server security capabilities:secure ID, compression method, and initial random number. Server_hello Phase 2 and 3 Server & Client Authentication and Key Exchange Client_Key_ Server and client exchange Exchange authentication, type of key exchange, Server_Key_ and public-key parameters. Exchange Web Server Generating the Master Secret Keys Client-Shared Master Key Server and client create the shared master key and the cryptographic parameters. Server-Shared Master Key Phase 4 Finish Message Client Finish VPN Client and server exchange Finish Message and a hash of the Finish Message IPsec IKE v2 Server Finish TLS M. Mogollon – 01/08 - 39 • The cryptographic parameters of the session state are produced by the TLS handshake protocol, which operates on top of the TLS record layer. When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, authenticate each other (optional), and use public-key encryption techniques to generate shared secrets. • The Handshake Protocol can be divided into four phases. 39 VPN, IPSec and TLS Phase 1 Handshake Protocol Web Server Phase 1 Establishing Security Capabilities Client Client_Hello 1. A ClientHello.random number (28 bytes), which is used later in the protocol; 2. A CipherSuite list containing the combinations of cryptographic algorithms supported by the client (in order of the client's preference, first choice first); 3. A list of the compression methods supported by the client, sorted by client preference. Server_hello 1. A ServerHello.random number (28 bytes), different from the one sent by the client; 2. A CipherSuite list containing the combinations of cryptographic algorithms supported by the server (in order of the server's preference, first choice first); 3. A list of the compression methods supported by the server, sorted by the server. When the client sends a client_hello message, the server must When the client sends a client_hello message, the server must respond with a server_hello message, or else a fatal error will occur respond with a server_hello message, or else a fatal error will occur and the connection will fail. and the connection will fail. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 40 • Client_hello and server_hello messages are used to establish security enhancement capabilities between client and server. The client_hello and server_hello establish the following attributes: protocol version, session_ID, cipher_suites, and compression_method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random. • When a client first connects to a server, it is required to send the client_hello as its first message. The client can also send a client_hello in response to a server_hello request. The client_hello message to the server includes these elements: • Client_version: The version of the TLS or SSL protocol by which the client wishes to communicate during this session. This should be the most recent (highest valued) version supported by the client. • Random: A client-generated random structure that consists of (1) The current time and date in standard UNIX in a 32-bit format, according to the sender's internal clock; and (2) 28 bytes generated by a secure random number generator. These values serve as nonces and are used to detect replay attacks during key exchanges. • Cipher_suites: This is a list of cryptographic algorithm options supported by the client (in order of the client's preference, first choice first). Each cipher suite defines a key exchange algorithm, a symmetric encryption algorithm (including secret key length), and a MAC algorithm. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection. The cryptographic options supported by the client are sorted with the client's first preference first. The cipher_suites have two sections: (1) The type of key exchange supported; and (2) Information about encryption algorithms and hash functions supported. • Compression_methods: This is a list of the compression methods supported by the client, sorted by client preference. • Session_ID: This is the ID of the session the client wishes to use for this connection. This field should be empty if no session_ID is available or if the client wishes to generate new security parameters. 40 VPN, IPSec and TLS Phase 2 Handshake Protocol Web Server Server Authentication and Key Exchange Client 1. Server sends its authentication certificate, using a X.509.v3 certificate. 2. Information about the type of key exchange the server is proposing. — — — — RSA: The secret key is encrypted with the server’s private key. Fixed Diffie-Hellman: The server’s certificate has the Diffie-Hellman parameters, signed by a Certificate Authority (CA). Ephemeral Diffie-Hellman: The Diffie-Hellman parameters are signed using the server’s RSA or DSA. Anonymous Diffie-Hellman: The Diffie-Hellman parameters are not signed. Key Exchange Parameters for RSA or Diffie-Hellman — — RSA: The modulo of the server's temporary RSA key and the public exponent of the server's temporary RSA key. Diffie-Helman: – The prime modulus p used for the Diffie-Hellman operation. – The generator g used for the Diffie-Hellman operation. – The server's Diffie-Hellman public value y (y = gx mod p). 3. A message requesting a client certification (optional); 4. A message indicating that the handshake of phase 2 is complete. Key Exchange Parameters Signing = ESPriv[Hash(ClientHello.random ║ ServerHello.random ║ ServerParams)] VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 41 • In Phase 2, immediately following the hello messages, the server sends (1) Its authentication certificate, using an X.509.v3 certificate (or a modified X.509 certificate, in the case of Fortezza); (2) The server key exchange; (3) A message requesting a client certification (optional); and (4) A message indicating that the handshake of phase 2 is complete. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm; it is generally an X.509.v3 certificate. • In TLS, the following key exchange methods are supported: o RSA: The secret key is enciphered with the server’s private key. o Fixed Diffie-Hellman: The server’s certificate has the Diffie-Hellman parameters, signed by a certificate authority (CA). o Ephemeral Diffie-Hellman: The Diffie-Hellman parameters are signed using the server’s RSA or DSS. o Anonymous Diffie-Hellman: The Diffie-Hellman parameters are not signed. • Regardless of the key-exchange method, the server needs to specify the parameters for the key exchange. The server key-exchange message conveys cryptographic information to allow the client to communicate the pre-master secret: either an RSA public key to encrypt the pre-master secret with, or a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the pre-master secret). • The server key exchange parameters are signed by creating a hash (MD5 or SHA) of the parameters and encrypting it with the server’s private key. 41 VPN, IPSec and TLS Phase 3 Handshake Protocol Web Server Client Authentication and Key Exchange Client 1. 2. Client verifies whether or not the server’s certificate is valid. Client sends certificate, if the server has requested it. — 3. Pre-master key exchange — — 4. Client must send either the certificate message or a no_certificate alert; this alert is only a warning. If client authentication is required, the server may respond with a fatal handshake failure alert. RSA: A 48-byte pre-master secret key, encrypted with the server’s RSA public key. Diffie-Helman: Both client and server perform the Diffie-Hellman calculation to create a pre-master key. Master Key generation — Once the pre-master key has been created, either from RSA or from DiffieHellman, the master key is computed as follows: Master_Key = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) Master_Key = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) PRF = Pseudo Random Function. See slide 20 VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 42 • In Phase 3, the client determines whether or not the server’s certificate is valid. If the certificate is valid, then the server’s public key is authentic and the client is sure that the server is who it claims to be. • If the server has sent a certificate request message, the client must send either the certificate message or a no_certificate alert. This alert is only a warning; however, the server may respond with a fatal handshake failure alert if client authentication is required. • Once the pre_master key has been created, either from RSA or from Diffie-Hellman, the master_secret key is computed as follows: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) 42 VPN, IPSec and TLS Phase 4 Handshake Protocol Web Server Finish Client 1. Client and server update the cipher_spec with the new, agreed-upon encryption algorithms, keys, and hash functions. 2. Client sends a “finished message” using the just negotiated encryption algorithms, hash functions, and symmetric encrypting keys to verify that the key exchange and authentication processes were successful. 3. The finished message is hashed as follows: — MD5[master_secret ║ pad2 ║ MD5(handshake_messages ║ Sender ║ master_secret ║ pad1)] — SHA[master_secret ║ pad2 ║ SHA(handshake_messages ║ Sender ║ master_secret ║ pad1)] Pad1 and pad 2 are the values defined in the MAC Handshake refers to all handshake messages exchanged Sender is a code that identifies that the sender is a client (0x434C4E54) or a server (0x53525652). Client and server may begin sending confidential data immediately after Client and server may begin sending confidential data immediately after sending the Finish message. The master secret is used as an entropy sending the Finish message. The master secret is used as an entropy source to generate random values for the export and non-export MACS, source to generate random values for the export and non-export MACS, secret keys, and initialization values (IV) required to encipher the data. secret keys, and initialization values (IV) required to encipher the data. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 43 • In this phase, the client and server update the cipher_spec with the newly agreed-upon encryption algorithms, keys, and hash functions. Then, the client sends a finished message to verify that the key exchange and authentication processes were successful. The finished message is the first protected message with the just-negotiated encryption algorithms, hash functions, and symmetric encrypting keys. The finished message is hashed as follows: • MD5(master_secret || pad2 || MD5(handshake_messages || Sender || master_secret || pad1)); • SHA(master_secret || pad2 || SHA(handshake_messages || Sender || master_secret || pad1)); • Where pad1 and pad 2 are the values defined in the MAC, “handshake” refers to all handshake messages exchanged, and “sender” is a code that identifies whether the sender is a client (0x434C4E54) or a server (0x53525652). • No acknowledgment of the finished message is required and, at this point, client and server may begin sending confidential data immediately after sending the finished message. 43 VPN, IPSec and TLS Key Calculation - Pre Master Key Generation Client Web Server Method 1 RSA – 48-byte Generated by the Client Server’s Certificate Server’s Public Key Server’s Secret Key Pre Master Key Encipher Decipher RSA RSA Pre Master Key Method 2: Diffe-Hellman Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Pre Master Key Pre Master Key VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 44 • In the client key-exchange message, the client sets the pre-master key either though direct transmission of the RSA-encrypted secret, or by the transmission of the client Diffie-Hellman public key, which will allow each side to agree upon the same pre-master secret. When the keyexchange method is DH_RSA or DH_DSS, client certification has been requested, and the client is able to respond with a certificate. The Diffie-Hellman public-key parameters (group and generator) match those specified by the server in its certificate; otherwise, the client proposes its own DiffieHellman public-key parameters (group and generator). • The RSA or Diffie-Hellman parameters for the pre_master key are the following: o RSA: A 48-byte pre_master_secret key, enciphered with the public key from the server's certificate or the temporary RSA key provided in a server key_exchange message. This pre_master_secret key is used to derive the master_secret key. o Diffie-Hellman: The client’s Diffie-Hellman public value (gX mod p). If Diffie-Hellman is used, both client and server perform the Diffie-Hellman calculation to create a pre_master key. 44 VPN, IPSec and TLS Key Calculation – Key and MAC Secrets Client Web Server Exchange (wrap / transport ) or agree on (Diffie-Hellman) a pre-master key. Pre_Master_ Key Pre_Master_ Key Master_Key Generation Master_Key Generation Key_Block prf Expansion Key_Block prf Expansion Client MAC Server MAC Client Key, IV Server Key, IV Symmetric Block Encryption Encipher VPN Client MAC Server MAC Integrity IPsec Confidentiality Symmetric Block Encryption Client Key, IV Server Key, IV Decipher IKE v2 TLS M. Mogollon – 01/08 - 45 • The record protocol requires an algorithm to generate keys and MAC secrets from the security parameters provided by the Handshake Protocol. As stated before, the master_secret generated during the Authentication and Key Exchange is used as an entropy source to generate keys and MAC secrets. The key material is generated as follows: key_block = PRF (SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random || SecurityParameters.client_random) until enough key material is generated for the following four items: client write MAC secret, server write MAC secret, client write key, and server write key. • The master secret is a 48-byte secret shared between the two peers in the connection. The client random is a 32-byte value provided by the client, and the server random is a 32-byte value provided by the server. • The pseudorandom function (PRF) is used to expand secrets into blocks of data for the purposes of key generation or validation. The PRF takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length. In the key_block formula above, the identifying label is “key expansion,” which is the ASCII string of “key expansion”. In order to make the PRF as secure as possible, it uses two hash algorithms in a way that should guarantee its security if at least one algorithm remains secure. 45 VPN, IPSec and TLS TLS – Pseudo Random Function Secret Label (Password) S1 S2 PRF(secret, label, seed) = P_MD5 (S1, label ║ seed) XOR P_SHA-1 (S2, label ║ seed) The PRF is created by splitting the secret key into two and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1. Then, the outputs of these two expansion functions together are XORed. • The label is an ASCII string. For example, the label "plano tx" would be processed by hashing the following bytes (hex): 70 6C 61 6E 6F 20 74 78. • The P_Hash data expansion function is used to create a pseudo random function (PRF). VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 46 • The P_hash data expansion function is used to create a pseudorandom function (PRF). TLS's PRF is created by splitting the secret in half and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1. Then, the outputs of these two expansion functions are XORed together. 46 VPN, IPSec and TLS TLS – P_hash (secret, seed) Seed Secret ║ HMAC A1 ║ HMAC Secret A2 Secret ║ HMAC A3 Secret HMAC(secret, A(1) ║ seed) HMAC(secret, A(2) ║ seed) HMAC HMAC(secret, A(3) ║ seed) P_hash(secret, seed) = HMAC_hash (secret, A(1) ║ seed) ║ HMAC_hash (secret, A(2) ║ seed) ║ HMAC_hash (secret, A(3) ║ seed) ║ ... VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 47 • The data expansion function, P_hash(secret, data) uses a single hash function to expand a secret and seed into an arbitrary quantity of output. The P_hash(secret, data) is calculated as follows: • P_hash(secret, seed) = HMAC_hash(secret, A(1) ║ seed) ║ HMAC_hash(secret, A(2) ║seed) ║ HMAC_hash(secret, A(3) ║ seed) ║ ... Where, A() is defined as: A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) • P_hash can be reiterated as many times as is necessary to produce the required quantity of data. For example, if P_SHA-1 were being used to create 64 bytes of data, it would have to be reiterated 4 times (through A(4)), creating 80 bytes of output data. The last 16 bytes of the final iteration would then be discarded, leaving 64 bytes of output data. • SHA-1 output is 160 bits or 20 bytes. 47 VPN, IPSec and TLS TLS Alert Protocol • Alert messages convey information about the status of the connection. • There are two types of alerts: Fatal and Warning. Fatal Alert: Indicates that the connection is so bad that it needs to be terminated immediately. Warning Alert: Indicates that there are some problems in the connection. • Error Alerts unexpected_message: An inappropriate message was received. Fatal. bad_record_mac: This alert is returned if a record is received with an incorrect MAC. Fatal. decompression_failure: The decompression function received improper input. Fatal. handshake_failure: Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. Fatal. illegal_parameter: A field in the handshake was out of range or inconsistent with other fields. Fatal. no_certificate: A no_certificate alert message may be sent in response to a certification request if no appropriate certificate is available. bad_certificate: A certificate was corrupt, contained signatures were not verifiable. unsupported_certificate: A certificate was of an unsupported type. certificate_revoked: A certificate was revoked by its signer. certificate_expired: A certificate has expired or is not currently valid. certificate_unknown: Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 48 • When an error is detected in the TLS Handshake Protocol, the detecting party sends an alert message to the other party. The SSL Record layer supports alert messages that convey information about the status of the connection. There are two types of alerts: Fatal and Warning. A Fatal alert message indicates that the connection is so bad that it needs to be terminated immediately. A Warning alert message indicates that there are some problems in the connection. Like other messages, alert messages are enciphered and compressed, as specified by the current connection state. 48 VPN, IPSec and TLS SSL VPN SSL VPN Gateway • Web Applications • Client/Server • Telnet • SSH • Email • File Transfer Internet SSL (TLS) Secure Connection S S L Applications Proxy Socks Address Translation Kiosk • • • • • Provides secure remote access to corporate applications. Uses SSL & TTL as the underlying transport to establish a secure session between any web browser and the proxy server in the SSL VPN Gateway. Presents users with a web portal containing links to applications. Functions as a proxy for both client (web browser) and server (web server) – there is never a direct connection to the private network. Ensures that authorized users have access only to specific resources as allowed by the company security policy implemented by the proxy server and integrated traffic management. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 49 • An SSL VPN uses SSL and proxy technology to provide authorized and secure access for endusers to HTTP, client/server, and file sharing resources. SSL VPNs use SSL & TTL as the underlying transports to establish a secure session between any Web browser and the proxy server in the SSL VPN Gateway. It functions as a proxy for both client (Web browser) and server (Web server) – there is never a direct connection to the private network. The proxy technology in SSL VPNs gives a Web browser access to applications that SSL alone doesn’t provide. • In a SSL VPN (proxy server), two connections are established: one between the Web browser in the non-secure network and the SSL VPN proxy, and another connection between the SSL VPN proxy and the endpoint in the secure network. The proxy prevents users from making a direct connection into a secured network. A SSL VPN proxy acts as a server to the client and as a client to the server. • The SSL VPN ensures that authorized users have access only to specific resources, as allowed by the company security policy implemented by the SSL VPN proxy and integrated traffic management. • Proxy servers break the TCP/IP connection between client and server so the packet’s IP address is not forwarded. They eliminate the exposure of internal IP addressing details to the non-secure network by hiding the IP address of the endpoint on the secure network. Only the public IP address of the proxy server is visible from the non-secure network. • When an application client needs to connect to an application server, the client connects to a SOCKS proxy server. The proxy server connects to the application server on behalf of the client and relays data between the client and the application server. For the application server, the proxy server is the client. 49 VPN, IPSec and TLS SSL VPN Threats • User passwords may remain on public-computers after users log off. — User passwords are stored by the browser. • Sensitive data, such as browser cache entries, URL entries, cookies, and any historical information created during the session, may remain on public computers after users complete their SSL VPN sessions. • Downloaded files are stored in the public computer’s “Temporary Folder.” • Users forget to logout. — Next public computer user may have access to applications. • Worms and viruses may be transferred from the public computers to the corporate internal network. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 50 • The following are considered threats to an SSL VPN: o Sensitive information may be left on computers at insecure locations. o User passwords may remain on public-computers after users log off. o User passwords are stored by the browser. o Sensitive data, such as browser cache entries, URL entries, cookies, and any historical information created during the session, may remain on public computers after users complete their SSL VPN sessions. o Downloaded files are stored in the public computer’s temporary folder. o Users forget to logout. o Next public computer user may have access to applications. o Worms and viruses may be transferred from the public computers to the corporate internal network. 50 VPN, IPSec and TLS IPsec and TLS: Complementary Solutions Ideal Overkill / Complex SSL Solutions Appropriate Comments IP Sec Telecommuter Inappropriate IPsec provides secure access to all network resources and applications. SSL requires legacy applications to be first ‘translated’ into HTTP or will give access to SSL-enabled apps only. Eg. Employee working from Home Office Site-to-Site VPN IPsec provides a secure tunnel between permanent locations Eg. Remote branch office requires connectivity to corporate WAN Remote Webmail SSL allows secure access from any web browser. Eg. Outlook Web Access, Lotus iNotes Internal Application Security SSL provides application layer security within VPNs Eg. HR Self-service Partner Extranet SSL doesn’t require installation of software on partner’s equipment but no control on workstation security IPsec might require firewall reconfiguration – need to police access but closer control on workstation security Eg. Supplier access to inventory system Web Application Portals SSL is simplest choice for native web apps. IPsec is overkill Eg. iPlanet, web-enabled enterprise apps, custom web apps. VOIP security VOIP can’t be carried by SSL IPsec is the solution for VOIP encryption Eg. Either site-to-site or telecommuter VOIP security. Wireless LAN security IPsec provides secure access to all network resources and applications. SSL requires legacy applications to be first ‘translated’ into HTTP or will give access to web apps only Eg. Securing WLAN access to the network by using stronger authentication and encryption. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 51 51 VPN, IPSec and TLS To Probe Further • Atkinson, R. (1995). IP Encapsulating Security Payload (ESP). RFC 1827. • Gleeson B., Lin A., Heinanen J, Armitage G., Malis A. (2000). A Framework for IP Based Virtual Private Networks. RFC 2764. • C. Kaufman, Ed. (2005). The Internet Key Exchange (IKEv2). RFC 4306. • Kent, S., Seo K. (2005). Security Architecture for the Internet Protocol. RFC 4301. • Kent, S. (2005). IP Authentication Header. RFC 4302. • Kent, S. (2005). IP Encapsulating Security Payload (ESP). RFC 4303. • Madson, C., Glenn, R. (1998). The Use of HMAC-SHA-1-96 within ESP and AH. RFC 2404. • Orman, H. (1998). The OAKLEY Key Determination Protocol. RFC 2412. VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 52 52 VPN, IPSec and TLS To Probe Further • Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., & Wright, T. (2006). Transport Layer Security (TLS) Extensions. RFC 4366, IETF. http://www.ietf.org/rfc/rfc4366.txt?number=4366 • Dierks, T., Rescorla, E. (2006). 4346 The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346, IETF. http://www.ietf.org/rfc/rfc4346.txt?number=4346 • Freier, A., Karlton, P., & Kocher, P. The SSL Protocol Version 3.0. Internet-Draft, November 1996. • Santesson, S. (2006). TLS Handshake Message for Supplemental Data. RFC 4680, IETF. http://www.ietf.org/rfc/rfc4680.txt?number=4680 • Santesson, S., Medvinsky, A., & Ball, J. (2006). TLS User Mapping Extension. RFC 4681, IETF. http://www.ietf.org/rfc/rfc4681.txt?number=4681 VPN IPsec IKE v2 TLS M. Mogollon – 01/08 - 53 53 ...
View Full Document

Ask a homework question - tutors are online