VPN Technologies

Although IPsec-based VPNs represent one of the most secure and widely deployed types of VPNs, they are only one of many VPN technologies in existence today. As we'll discuss throughout the course of this book, VPNs have been designed to protect data at almost every layer of the OSI stack. For example, customers in different market verticals will deploy a range of encryption technologies, from Layer 1 bulk encryptors to encryption technologies embedded within the applications themselves (SSL-based VPNs).

The OSI model consists of 7 layers, Physical, Data-Link, Network, Transport, Session, Presentation, and Application. Although our primary focus will be IPsec VPNs, which are a Layer 3 VPN technology, it is important to understand IPsec VPNs within the context of other VPN technologies corresponding to different layers within the OSI stack. Figure 1-4 illustrates the OSI stack and provides some examples of VPN technologies that operate at each corresponding OSI layer

Figure 1-4. VPN Technologies and the OSI Model

Virtual Private Dialup Networks

Virtual private dialup networks (VPDN) are used to tunnel data across a shared media. Although the primary goal of a VPDN is to tunnel data across shared network infrastructures, some VPDNs may also incorporate data confidentiality. Most VPDNs rely on the use of PPP to encapsulate data in transit across a common network infrastructure. Typical VPDN deployments consist of one or many PPP clients establishing a PPP session that terminates on a device at the opposite end of the tunnel, usually located at a central location within the enterprise or service provider edge. In doing so, a secure point-to-point tunnel is established from the client's network to the PPP concentrator. After the tunnel has been established, the client's network appears as if it were the same network as the enterprise side, while the underlying common network infrastructure across which data is tunneled remains unchanged. Common VPDN technologies deployed in today's networks include Layer 2 Forwarding Protocol, Point-to-Point Tunneling Protocol, and Layer 2 Tunneling Protocol.

Layer 2 Forwarding Protocol

The Layer 2 Forwarding (L2F) Protocol was originally developed by Cisco Systems as a way to tunnel privately addressed IP, AppleTalk, and Novell Internet Protocol Exchange (IPX) over PPP or Serial Line Internet Protocol (SLIP) dialup connections over shared networks. In order to do this, this VPDN technology concentrates tunnels at a home gateway, allowing all dial-up networks to appear as if their physical point of termination is the home gateway itself, regardless of the location of their actual dialup termination point. L2F uses control messages on UDP port 1701 to establish the session. Once a tunnel is established, L2F-encapsulated packets are forwarded in parallel with L2F control datagrams. Both L2F control and payload datagrams are forwarded on UDP 1701. The L2F encapsulated PPP packets have the format described in Figure 1-5.

Figure 1-5. L2F Data Packet Format

During the creation of an L2F tunnel, initially a user dials into the Network Access Server (NAS), negotiates PPP, and is authenticated with either Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), as illustrated in Figure 1-6.

Figure 1-6. L2F Topology and Tunnel Establishment

Note

In an L2F environment, a "home" gateway refers to a gateway located at the corporate headquarters.

The following steps describe the creation of an L2F tunnel, as illustrated in the steps in Figure 1-6:

1.	NAS and the PPP client negotiate a PPP session. NAS authenticates the PPP client with CHAP (or, optionally, PAP). Note The NAS can optionally authenticate PPP connections against the AAA (or in this case, Cisco Secure Access Control Server) server in the service provider cloud. Managing user connections centrally would ease the administrative burden and provide additional accounting and user database synchronization capabilities (that is, synchronization with NT databases and automated backup of AAA data on peer CSACS databases). Once the PPP session has been authenticated, a series of exchanges are performed to offload the termination of the dialup session to the home gateway. Figure 1-7 illustrates the CHAP handshake between the PPP client and the NAS shown in Figure 1-6. Figure 1-7. PPP Authentication with CHAP
2.	NAS initiates a tunnel connection to the home gateway.
3.	The home gateway authenticates NAS against the authentication database (RADIUS or TACACS+).
4.	The home gateway confirms acceptance of the tunnel negotiation initiation request from NAS.
5.	The home gateway and PPP client negotiate additional authentication, authorization, accounting, IP addressing, and tunneling parameters.
6.	An L2F tunnel is established and maintained between the PPP client and the home gateway. Note For more information on L2F, refer to RFC 2341 at http://www.ietf.org/rfc/rfc2406.txt.

Point-to-Point Tunneling Protocol

Point-to-point Tunneling Protocol (PPTP), a technology originally created by Microsoft, provides a seamless integration of remote PPP capable devices into an enterprise network. PPTP leverages authentication parameters inherent to native PPP and the tunneling capabilities of GRE to establish a VPDN. After a client has established a PPTP tunnel to a concentrator on a centralized enterprise network resource, that client appears as if it were part of the enterprise network itself, regardless of the underlying common infrastructure that the data is tunneled across. Consider the following exchange between a small remote office network (the PPP client) and a corporate VPDN (PPTP) concentrator. Figure 1-8 illustrates the order of operations executed when a client accesses the VPDN using PPTP.

Figure 1-8. PPTP Topology and Tunnel Negotiation

The PPP client in this scenario needs to connect to their enterprise network. The corporation's security policy mandates that data be separated from the common service provider infrastructure and that central network connectivity provided by the service provider must remain transparent to the PPP clients, who are PSTN or ISDN attached. In order to accomplish this task, PPTP is used to provide an end-to-end tunnel for PPP connections inbound to the service provider.

Generally, there are two different types of PPTP VPDN tunnels: compulsory tunnels and voluntary tunnels. Compulsory tunnels are formed when a PPP client accesses the NAS or PPTP Access Concentrator (PAC). The NAS/PAC in turn establishes a tunnel with the PPTP Network Server (PNS). Voluntary tunnels are formed when a PPP client directly negotiates a PPTP tunnel with the PNS. The creation of a voluntary PPTP tunnel executes the following steps (illustrated in Figure 1-8):

1.	The first step in the negotiation occurs when the PPP client establishes a connection with the NAS and is authenticated through a chosen form of PPP authenticationPAP, CHAP, or Microsoft CHAP (MS-CHAP). PPTP tunnels can be encrypted through the use of Microsoft Point-to-Point Encryption (MPPE) to provide confidentiality in VPDNs. Cisco IOS supports both 40- and 128-bit MPPE encryption. In order to encrypt a PPTP tunnel using MPPE, the network administrator must use MS-CHAP to authenticate PPP connections to the NAS. Tip Authentication of PPP sessions can be passed to a centrally managed authentication database, such as CSACS via RADIUS or TACACS+. Authenticating PPP sessions against a CSACS database greatly eases administration of user authentication data for VPN access.
2.	Now that the PPP client has accessed the service provider network, the client has IP connectivity to the PNS at its corporate headquarters. The PPP client and the PNS must maintain two connections to one anothera control connection and a tunnel protocol connection. The PPTP control connection maintains the connection state and negotiates call setup and teardown. As such, it must be established before the tunnel protocol connection can be established. Once an NAS receives the call from the PPP client, the next step in creating the VPDN connection is to either establish a compulsory tunnel from the NAS/PAC to the PNS or to establish a voluntary tunnel from the PPP client itself to the PNS. In Figure 1-8, the PPP client elects to establish a voluntary tunnel directly to the PNS. In this scenario, the PIX is acting as the PNS for the PPTP exchange. The client initiates the tunnel by establishing a TCP connection to the PNS on port 1723. Caution In many cases, including the example in Figure 1-8, TCP port 1723 must be allowed through any corporate firewalls or other filtering security devices for PPTP to operate correctly. In this scenario, the PIX would be configured with the appropriate static translation and access list entry on its outside interface to allow TCP sessions from remote clients on port 1723.
3.	Once the PPP client and the PNS have TCP connectivity, they can start to exchange PPTP tunnel negotiation information between them. The tunnel negotiation process consists of exchanging connection request and reply messages as defined in RFC 2673 between the PNS and the PPP client. Tip As with PPP authentication on the NAS/PAC, PPTP connections on PIX firewalls and Cisco routers can be authenticated against a Cisco Secure ACS database using RADIUS or TACACS+. Implementing user accounts on a central CSACS database greatly eases administrative overhead.
4.	Once the PPTP control connection has negotiated call setup, call maintenance, and tunnel parameters accordingly, a second session is establishedthe PPTP tunnel connection itself. The PPTP tunnel connection uses a modified version of GRE to tunnel PPP frames over the IP cloud, which, in Figure 1-8, is the service provider network. The GRE-encapsulated format of the PPTP tunneled packet is illustrated in Figure 1-9. Figure 1-9. PPTP Tunnel Protocol Data Structure

Note

The header used in the PPTP encapsulation process is similar to a GRE header, with some slight modifications to the specification outlined in RFC 1701. The PPTP version of the GRE header includes an acknowledgment field to determine the rate at which packets are traversing the PPTP tunnel.

The preceding scenario describes a voluntary PPTP tunnel negotiation between the PPP client, which also acts as its own PAC, and the corporate PIX Firewall, acting as the PNS. In a compulsory PPTP tunnel negotiation, the NAS would act as the PAC and would multiplex multiple sessions from the PPTP clients into a single tunnel to the PIX, or PNS. The exchanges in a compulsory tunnel would follow the same steps chronologically, but would appear as displayed in Figure 1-10.

Figure 1-10. A PPTP Compulsory Tunnel Setup between PAC and PNS

Note

Although both L2TP and PPTP support both voluntary and compulsory tunnels, Cisco IOS only supports voluntary and compulsory tunnels for L2TP. While voluntary PPTP tunnels are supported in Cisco IOS, compulsory PPTP tunnels are currently not supported.

As depicted in Figure 1-10, only a single tunnel is negotiated between the PAC/PNS pair. In a voluntary exchange, it is possible that all 5 PPP clients dialing into the NAS terminate separate tunnels with the PIX/PNS. As such, compulsory tunnel architectures can be used to keep tunnel termination overhead low on the PNS. In the examples in this chapter, the voluntary tunnel negotiation option could yield up to five times the tunnel maintenance of a compulsory tunnel negotiation option (five PPP clients initiating tunnels to the PIX in a voluntary arrangement vs. one tunnel initiated from the NAS in a compulsory setting).

Compulsory tunnels, however, do not offer end-to-end confidentiality with MPPE. In the preceding compulsory arrangement, the PPP connections to the NAS would remain unencryptedonly the connection from the PAC to the PNS would be encrypted with MPPE. As such, those network administrators requiring fully confidential exchange of data in their PPTP environments should choose to allow their clients to voluntarily negotiate an end-to-end PPTP tunnel with the PNS or, in this case, the corporate PIX Firewall. In doing so, the network administrator can ensure that all legs of the VPDN from their remote dialup hosts using PPP to their corporate PNS are encrypted for end-to-end data confidentiality.

Layer 2 Tunneling Protocol

Layer 2 Tunneling Protocol (L2TP) is a collaborative effort to develop a standards-based VPDN protocol within IETF. Vendors collaborating on this initiative include, among others, Cisco and Microsoft. As with PPTP, L2TP is a client-server operation consisting of two main components:

• L2TP Access Concentrator (LAC) The LAC represents the client side of this network and typically exists on the switch infrastructure between remote dialup nodes and the access server that terminates the inbound PPP sessions across the switched ISDN or PSTN infrastructure. As remote hosts initiate and terminate PPP connections on the NAS, the LAC serves as a proxy originator of L2TP control and tunnel data to the LNS at the corporate network. LACs are often collocated with the access server itself. A Cisco router or access server is capable of providing LAC functionality within a VPDN.

• L2TP Network Server (LNS) The LNS represents the server side of this VPDN architecture. It resides within the enterprise network and terminates tunneled data from the LAC. As users connect to the LAC, connections are multiplexed across the negotiated tunnel to the LNS, where they are eventually terminated.

A typical L2TP session resembles a compulsory PPTP tunnel negotiation between a PAC and a PNS. As with PPTP, two types of data are forwarded into an L2TP tunnelcontrol data and tunnel data. Unlike PPTP, however, L2TP is not connection oriented. Instead, it is packet oriented. So, whereas PPTP relied on a TCP-based connection to establish a control channel between the PAC and PNS, L2TP uses UDP to maintain control data and tunnel data simultaneously. L2TP leverages the use of control messages and data packets as follows:

• L2TP control messages negotiate tunnel setup and maintenance. Control messages establish tunnel IDs for new connections within an existing tunnel. They also tear down and remove previously established tunnel IDs within an existing L2TP tunnel. L2TP control messages are originated on a given source port and forwarded to UDP destination port 1701.

• L2TP payload packets tunnel data within a given network. When data is tunneled from LAC to LNS across an IP cloud, it is encapsulated with an L2TP header. The format of the L2TP payload is illustrated in Figure 1-11. As with L2TP control messages, L2TP payload packets are forwarded to UDP 1701.

  Figure 1-11. L2TP Tunnel Protocol Data Structure

  

Note

L2F control and payload packets are also sent on UDP port 1701. Network devices inspect the version field to differentiate between L2F and L2TP packet formats.

Figure 1-12 depicts a sample L2TP tunnel setup in which a company uses L2TP to establish seamless, secure connectivity across an untrusted media. In this case, that shared network is the ISP cloud. The ISP owns the access server that terminates the customer's dialup connection using PPP as the Layer 2 protocol. In this example, the access server also serves as the LAC. The LNS is located on the customer premises and terminates the L2TP tunnel originated from the LAC.

Figure 1-12. L2TP Tunnel Negotiation

The following steps outline the creation of the L2TP VPDN from the remote host to the corporate network as described in Figure 1-12:

1.	The user dials in to the NAS/LAC over PSTN or ISDN. The user establishes a PPP connection with the NAS and is authenticated with CHAP.
2.	The user initiates an L2TP tunnel and is prompted for a username and password. The ISP inspects the remote user's username and authenticates it against its central authentication database via TACACS+ or RADIUS.
3.	Once authenticated, the LAC initiates an L2TP tunnel to the LNS located at their corporate facility.
4.	The LNS receives the request for tunnel negotiation and optionally authenticates the request against the corporate central authentication database via TACACS+ or RADIUS. The LNS responds with either an acceptance or a rejection of the tunnel initiation to the LAC.
5.	The LNS creates a virtual interface for the tunnel ID corresponding to the requesting remote PPP client. The remote PPP client and the LNS are now able to exchange authentication, authorization, accounting, and IP addressing data with one another over the tunneled PPP session. L2TP headers are stripped on ingress at the LNS for inbound connections from the PPP client. Likewise, L2TP headers are stripped at the LAC for outbound connections from the LNS to the PPP client.
6.	A PPP connection now exists between the PPP client and the LNS. Additionally, an L2TP tunnel has been negotiated between the LAC and the LNS. When a new PPP client attempts to access the corporate network and is authenticated at the ISP, the LAC does not create a new L2TP tunnel but instead adds a new tunnel ID to the existing tunnel for that client.

Multiprotocol Label Switching VPNs

Multiprotocol Label Switching (MPLS) VPNs logically separate VPN traffic over a shared media through the use of VPN Routing and Forwarding Instances (VRFs). In an MPLS network, different devices play different roles to achieve this logical separation:

• Provider (P) Router: P routers typically comprise the MPLS core and therefore provide transport between PE routers. Instead of using IP routing information base (RIB) or IP forwarding information base (FIB) lookups to make forwarding decisions, P routers use a label forwarding information base (LFIB) lookup to make their forwarding decisions. Convergence of the LFIB between P routers in the provider network is facilitated through the use of Label Distribution Protocol (LDP).

• Provider Edge (PE) Routers: PE routers typically provide the interface between the service provider and the customer, and it is most common for the provider to own the PE router. PE routers communicate information about VPNv4 addresses, including the IPv4 prefix and 8-byte route descriptor, between one another using the Multiprotocol Border Gateway Protocol (MP-BGP), enabling convergence at the PE.

  Note

  MP-BGP plays a critical role in the convergence of an MPLS VPN. For more information on MP-BGP and its role in MPLS VPNs, please refer to the following IETF RFC:

  http://www.ietf.org/rfc/rfc2547.txt

  
  

• Customer Edge (CE) Routers: CE routers provide the interface to the PE routers. CE routers typically perform forwarding decisions based on standard RIB or FIB lookups, and convergence between CE routers and the PE router can typically be achieved through the use a standard IGP.

Caution

An MPLS VPN does not provide confidentiality unless it is deployed in conjunction with IPsec.

A VRF describes a separate routing and forwarding table, enabled by the use of Route Descriptors, which are 8-byte unique identifiers derived from VPN-specific information at the provider edge (PE). MPLS VPNs enable customer edge (CE) routers to establish normal Layer 3 RP adjacencies with MPLS-aware PE routers. Each PE router is MPLS VPN aware and is able to forward traffic to its destination PE router on the opposite side of the provider core using VPNv4 addresses learned from MP-BGP advertisements from other PE routers. The provider core routers remain unaware of the customer network's routing table or IP addressing information. Instead, traffic is switched within the MPLS cloud using labels and an entry in the P router's label forwarding information base (LFIB). Figure 1-13 illustrates IP-routed and VRF-routed domains with MPLS.

Figure 1-13. Traffic is IP-Routed to the Provider Edge (PE)

When the traffic from the customer edge reaches the PE router, it is then label switched across the MPLS Service Provider core to its destination PE router. In this manner, customer routing and IP addressing information is kept virtual and private from the provider corethe P routers use MPLS labels and an associated LFIB entry to forward the traffic across the MPLS core rather than IP addressing information.

When MPLS-switched traffic arrives at the destination PE router, traffic can be forwarded to neighboring CE routers based on the previously installed VPNv4 address learned from MP-BGP advertisements from neighboring MP-BGPenabled PE routers. The CE routers perform IP RIB lookups to determine the appropriate destination and forwarding decisions within the customer core IP network.

The operation of MPLS offers separation of multiple virtual data networks across a shared network such as an ISP. The addition of MPLS labels at the service provider core allows customers to separate networks from other customers virtually over a shared core network such as a service provider network. The use of route descriptors on PE nodes provides separation at the control plane, allowing customers to use overlapping address space and overlapping services that would normally present conflict within a non-MPLS environment. As mentioned previously, data-plane separation is achieved using VPN labels to make the forwarding decisions on PE routers.

IPsec VPNs

IPsec VPNs encrypt data at the Layer 3 IP packet layer, offering a comprehensively secure VPN solution through providing data authentication, anti-replay protection, data confidentiality, and data integrity protection. As such, IPsec is one of the most widespread VPN technologies in today's enterprise, service provider, and government networks. Using ESP in tunnel mode, IPsec supports the rewrite of Type of Service (ToS) bits into an outer IP header, thereby supporting encrypted data payloads while preserving quality of service (QoS) within a given network. IPsec is a standards-based protocol and therefore supports interoperability across products from multiple vendors.

Note

Although IPsec is standards based, there are many optional components of IPsec (not required for RFC compliance) and proprietary innovations that present compatibility considerations in multi-vendor environments. We will discuss these design considerations in greater detail in Chapter 8, "Handling Vendor Interoperability with High Availability."

As we will discuss, IPsec is supported within Cisco IOS on a wide array of different routers, firewalls, VPN Service Modules, VPN concentrators, and VPN clients. Likewise, Cisco offers a variety of different hardware-based VPN acceleration options for enhanced VPN performance within a network. IPsec will serve as the primary VPN discussion point for the duration of this book.

IPsec VPNs tunnel data across shared media using ESP, AH, or a combination of both. These two standards-based protocols both use symmetric encryption technology.

Note

The precise operation of ESP and AH are outlined more comprehensively in Chapter 2.

IPsec-supported symmetric encryption transforms include data encryption standard (DES, 56-bit transform), triple data encryption standard (3DES, 168-bit transform), and most recently, advanced encryption standard (AES, 256-bit transform). Security parameters, including keys used for symmetric encryption, are communicated securely using the Internet Key Exchange (IKE) protocol, which is also considered part of the IPsec protocol suite. The operation of protocols incorporated within the IPsec protocol suite is discussed in greater detail in Chapter 2. Subsequent chapters will explore design considerations of IPsec-based VPNs.

Transport Layer VPNs

Transport layer VPNs provide an additional layer of security at the transport of the OSI stack. Transport layer VPNs typically consist of a client application and a server. A transport layer VPN will undergo a handshake to agree on common parameters to use for the SSL or TLS session, including cryptographic keying material and transforms. The messages in this handshake are confidentially exchanged between client and server, typically with a form of public key encryption such as RSA encryption. During the handshake, the client and server also agree on a set of symmetric session keys and a symmetric key transform, such as DES or 3DES, for bulk data encryption over the SSL VPN.

Secure Socket Layer VPNs

In today's network architectures, Secure Socket Layer (SSL) VPNs represent one of the most popular choices for transport layer security. SSL was originally developed by Netscape in 1994 to secure client/server applications across the Internet. SSL is effective at providing data authentication, data integrity, and data confidentiality between client and server applications, but it does not offer data non-repudiation services. As discussed before, SSL is performed over TCP in the transport layer of the OSI stack, as illustrated in Figure 1-14.

Figure 1-14. SSL and the OSI Stack

SSL follows five broad steps when establishing a secure sessionclient exchange of cryptographic parameters, server exchange of cryptographic parameters, cryptographic key derivation, session authentication, and secure data exchange. Refer to the scenario illustrated in Figure 1-15 for the following description of SSL tunnel negotiation. In the SSL tunnel negotiation, public key encryption is typically used for initial client and server authentication. The client and server also exchange public keys to encrypt each message in the handshake. Once the handshake is completed, symmetric key transforms are used for bulk data encryption between client and server.

Figure 1-15. SSL Tunnel Establishment

The following order of operations describes the SSL handshake illustrated in Figure 1-15:

Note

RSA signatures are commonly used to facilitate the authentication and confidential exchange of messages during the SSL handshake. RSA Signatures, including x.509-based certificates and certificate authorities, are discussed in full detail in Chapter 2 and Chapter 12, "Public Key Infrastructures and IPsec."

1.	Client Exchange of Cryptographic ParametersThe client and server must agree on the parameters used for encryption, such as the encryption algorithm, key exchange method, and hash method to use for data integrity. If the client and server have not already agreed on these parameters, then the client will initiate the exchange of messages to negotiate mutually acceptable parameters to use for future operations using by sending a CLIENT-HELLO message to the concentrator.
2.	Server Exchange of Cryptographic ParametersThe server responds to the CLIENT-HELLO message with a SERVER-HELLO message and, optionally, several other messages: SERVER-CERTIFICATE Contains the servers's public key for server authentication and pre-master secret encryption. SERVER-KEY-EXCHANGE Optionally used to encrypt the CLIENT-KEY-EXCHANGE message in Step 3 below. CLIENT-CERTIFICATE-REQUEST The SSL concentrator or server can optionally request a client certificate for authentication. If this message is sent to the client, the client's server must be forwarded to the SSL concentrator and successfully validated. The SERVER-HELLO will specify the parameters to use for the SSL session, including the highest version ID and the strongest supported symmetric key cipher specified in the CLIENT-HELLO message from Step 1. At this point, the client and server should have the appropriate information necessary to agree on cryptographic parameters. A SERVER-HELLO-DONE message is then forwarded to the SSL client to indicate that the SSL server has received the required information for this sequence of the handshake and is awaiting information from the client (as described in the next step).
3.	Cryptographic Key DerivationThe client is now ready to generate and share its pre-master secret key with the SSL server. The pre-master secret is comprised of a 48-byte value (in the case where RSA is used). This value is then encrypted with the SSL server's public key and forwarded to the SSL server using a CLIENT-KEY-EXCHANGE message. Optionally, the client will also forward two additional messages at this point in the SSL handshake: CLIENT-CERTIFICATE The client must possess a certificate and forward it to the server using this message if the client receives a CLIENT-CERTIFICATE-REQUEST in Step 2 above. CERTIFICATE-VERIFY This message is a hash of all previous handshake messages appended. It is sent to the SSL server to validate the authenticity and data integrity of the CLIENT-CERTIFICATE message (and all other previous handshake messages) if the client receives a CLIENT-CERTIFICATE-REQUEST in Step 2 above. The SSL Server decrypts the CLIENT-KEY-EXCHANGE message to obtain the pre-master secret sent by the client. The client and server then derive the master secret by hashing the pre-master secret with the ClientRandom and ServerRandom values shared in Step 1. The master key is then used to derive 4 session keys that SSL will use to encrypt data: Client Write MAC Secret Client uses this key to create a hash appended to the original message; server uses this key to verify the hash. Server Write MAC Secret Server uses this key to create a hash appended to the original message; client uses this key to verify the hash. Client Write Key Client uses this key to encrypt messages; server uses it to decrypt messages. Server Write Key Server uses this key to encrypt messages; client uses it to decrypt message. The client concludes this phase of the SSL handshake by sending a CLIENT-FINISHED message to the server. The FINISHED message contains a hashed value of all previous messages in the handshake to this point. The server verifies this message to determine that the previous exchanges have indeed been authentic with preserved data integrity.
4.	Session AuthenticationThe SSL concentrator or server must validate the hash (MAC) sent in the client FINISHED message received in Step 3 above. Upon successful validation of the MAC contained in the client FINISHED message, the server now safely assumes that the SSL handshake has proceeded with authenticity and preserved data integrity. The server subsequently forwards a server FINISHED message to the SSL client containing a MAC resulting from a hash of all previous messages in the handshake to this point. Upon receipt of this message, the SSL client performs a validation of the MAC received in the server FINISHED message so that it too can assume that the handshake has completed with authenticity and preserved data integrity.
5.	Confidential Exchange of Data with Preserved IntegrityThe client and server now use the session keys derived from the master secret in Step 1 to encrypt and decrypt data sent to and from one another. This is done through an agreed-upon cipher transform such as DES or, in this case, 3DES. However, to ensure data integrity, a hashed message authentication code (HMAC) is appended to the original message. The newly formed payload (original message + HMAC) is encrypted with the selected transform.

Note

The creation of hashed message authentication codes is covered in greater detail in Chapter 2.

Transport Layer Security and SSL VPNs

SSL was originally developed by Netscape and has proven to be effective for HTTPS communications. However, the IETF standards track protocol for security at the transport layer is actually transport layer security (TLS). The operation of TLS is similar to SSL 3.0 but has significant modifications, specifically with respect to support for different cryptographic algorithms, that make the two incompatible with one another.

TLS has big implications in 802.1x identity-based networking systems, because extensible authentication protocol with TLS (EAP-TLS) is part of the 802.1x standard. Additionally, TLS is a critical component in wireless network security. Although not formally a component of the newly ratified 802.11i IEEE standard for wireless network security, EAP-TLS is the de facto means of authentication in 802.11i-compliant networks.