Modern Cryptography: Applied Mathematics for Encryption and Informanion Security (2016)
PART IV. Applications
Chapter 14. Virtual Private Networks
In this chapter we will cover the following:
Authentication
PPTP
L2TP
IPSec
SSL/TLS VPN
Secure communications
Virtual private networks (VPNs) are yet another very common application of cryptography. VPNs are designed to provide a secure connection between two sites or between a remote worker and a site. They give you the same connection you would have if you were physically connected to the network—thus the name: it is a virtual connection to a private network. In this chapter we will examine some general concepts as well as specific technologies related to VPNs. We will also look at related technologies that, while not strictly VPNs, are secure remote connections.
The Dictionary of Computer and Internet Terms defines a VPN as “a network where data is transferred over the Internet using security features preventing unauthorized access.”1 This is a fairly typical definition, similar to what you would find in any computer dictionary, but not quite detailed enough.
The idea of a VPN is to emulate an actual physical network connection, which means a VPN must provide the same level of access and security as well. To emulate a dedicated point-to-point (PTP) link, data is encapsulated, or wrapped, with a header that provides routing information that allows it to transmit across the Internet to reach its destination. This creates a virtual network connection between the two points. Next, the data is encrypted, thus making that virtual network private.
The question becomes, how does one implement the authentication and encryption required to create a VPN? Several technologies can facilitate establishing a VPN, and each works in a slightly different manner. We will examine each of these in this chapter. Despite the differences in the protocols, the end goals are the same. First authenticate the user to ensure that this user is who they claim to be. Then exchange cryptographic information such as what algorithms to use, and finally establish a symmetric key the two parties can use to secure data between them.
Authentication
Authentication is merely the process of verifying that some entity (be it a user or another system or program) is, indeed, who they claim to be. The most obvious example of authentication occurs when an end user provides a username and password. The password presumably verifies the user’s identity. However, as security breaches become more widespread, a simple username and password are no longer adequate. So other types of authentication have been developed:
Type I, something you know Passwords, PINs, and passphrases are classic examples of Type I authentication. They all have the same weakness, however: they can be easily guessed or stolen.
Type II, something you have These are physical items, such as a debit card used with ATMs, smart cards, and smart keys. This type of authentication cannot be guessed, but it can certainly be stolen.
Type III, something you are Biometrics, including fingerprints, retinal scans, facial recognition, even handwriting, all constitute Type III authentication. This is the most secure type of authentication, because it cannot be guessed and cannot be stolen (at least not easily!).
Note
These are the three primary means of authentication, but other methods exist. For example, out-of-band (OOB) authentication involves prompting the user for information from various data sources that is likely to be known only to the authentic user. When you run a credit report online, many systems will prompt you for identifying information such as a Social Security Number (Type I authentication) and ask you questions such as the amount of your monthly credit card payment and current balance. These last two pieces of information are OOB information.
Type I authentication can be used for VPNs and often is. Type II can also be used. The best solution, often called strong authentication, is to combine Type I and Type II authentication. For example, if you want to use an ATM, you must have a debit card (Type II) and a PIN (Type I). Some VPN solutions operate in a similar fashion, requiring a password and perhaps a digital certificate (see Chapter 13 for a detailed discussion of digital certificates), or even a smart card on the client machine. Type III authentication is not appropriate for VPNs in most situations (except for government-controlled classified systems). The cost, overhead, and complexity make biometrics less attractive for VPNs.
In addition to considerations as to what type of authentication to use, you must address the method of transmitting authentication data as well as cryptographic information. This is handled by VPN protocols. Each protocol establishes its own authentication method as well as how to exchange cryptographic data.
Because all VPN protocols include authentication as well as encryption, you need to have a good understanding of authentication protocols. Throughout this book, we have examined a number of cryptographic and hashing algorithms; compared to those, authentication is a relatively simple process. The purpose of authentication is simply to verify that a given entity is who they claim to be. Modern authentication protocols also prevent sophisticated attacks such as session hijacking.
Note
Session hijacking occurs when an attacker waits until a user has authenticated to a system and then takes over that session. Various methods can be used, all of which are at least moderately sophisticated. The key to session hijacking is that the attacker does not actually need to obtain the user’s password; the attacker takes over a session after the user has supplied the password to the system.
CHAP
Challenge Handshake Authentication Protocol was specifically designed to prevent session hijacking. The process of CHAP is relatively straightforward:
1. The client sends her username and password to the server (often called the “authenticator” in CHAP documentation).
2. The server/authenticator then requests that the client calculate a cryptographic hash and send that to the server.
3. Periodically, at random intervals, the server/authenticator will request that the client re-present that cryptographic hash. The purpose of this is to detect if session hijacking has occurred, and, if so, terminate that connection.
This process is depicted in Figure 14-1.
FIGURE 14-1 The CHAP process
Note
Microsoft created its own variation of CHAP, called MS-CHAP. Although MS-CHAP conforms to the general description, the variations are not pertinent to our discussions of VPNs. For example, MS-CHAP v2 provides for mutual authentication, wherein both sides authenticate each other.
EAP
Extensible Authentication Protocol, as the name implies, is a framework that can be modified, or extended, for a variety of purposes. The EAP standard was originally specified in RFC 2284, but that was supplanted by RFC 3748, and then later updated by RFC 5247. The various permutations of EAP differ in how authentication material is exchanged. There are many variations of EAP, so let’s take a look at just a few.
LEAP
Lightweight Extensible Authentication Protocol was developed by Cisco and has been used extensively in wireless communications. LEAP is supported by many Microsoft operating systems including Windows 7. LEAP uses a modified version of MS-CHAP.
EAP-TLS
Extensible Authentication Protocol–Transport Layer Security uses TLS (see Chapter 13) to secure the authentication process. Most implementations of EAP-TLS use X.509 digital certificates (also discussed in Chapter 13) to authenticate the users.
PEAP
Protected Extensible Authentication Protocol encrypts the authentication process with an authenticated TLS tunnel. PEAP was developed by a consortium including Cisco, Microsoft, and RSA Security. It was first included in Microsoft Windows XP.
EAP-POTP
Protected One-Time Password is a variation of EAP described in RFC 4793. It uses a onetime password token to generate authentication keys and can be used for one-way or bilateral authentication (the client authenticates to the server, and the server authenticates to the client).
An OTP is used only once, and then it is no longer valid. It is often used in conjunction with a device such as a key fob that generates the OTP. The key fob and the server use the same algorithm and tie in the current time stamp to generate the same OTP on both ends. Often this is used in conjunction with a traditional password.
Kerberos
Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using symmetric cryptography. It was originally developed at MIT under the name “Project Athena.” The protocol was named after the Greek mythological character Kerberos (or Cerberus), the monstrous three-headed guard dog of Hades.
Kerberos is widely used and has been implemented in versions from Windows 2000 to the current (Server 2012 as of this writing), as well as Red Hat Enterprise Linux, FreeBSD, IBM AIX, and other operating systems.
You should be familiar with several Kerberos-related terms:
Principal A server or client to which Kerberos can assign tickets
Authentication server (AS) A server that gives authorizes the principal and connects them to the Ticket-granting server
Ticket-granting server (TGS) A server that provides tickets
Key distribution center (KDC) A server that provides the initial ticket and handles TGS requests; often runs both AS and TGS services
Ticket-granting ticket (TGT) The ticket that is granted during the authentication process
Ticket Used to authenticate to the server; contains client identity, session key, timestamp, and checksum and is encrypted with server’s key
Session key Temporary encryption key
The process itself is purposefully complex to prevent session hijacking attacks and to ensure a more robust and reliable authentication mechanism. There are variations on the process depending on implementation, but the general process is as follows:
1. The client sends a username and password to the authentication server (also known as a server or a service). The username and password are used to generate a session key that the server uses to send messages to the client for this session. The authentication server/service (AS) is usually colocated with the ticket-granting service (TGS) on the key distribution center (KDC) server. Often, the KDC includes the AS and TGS.
2. After the AS has verified the client, it directs the TGS to generate a ticket-granting ticket (TGT). This includes, among other things, the client ID, client network address, client session key, and validity period. All of that information is encrypted with a symmetric key that only the TGS has—in other words, the client cannot decrypt the ticket.
3. When the client wants to access a given service, a message is sent to the KDC consisting of the TGT and the ID of the service requested. A second message is also sent that has the client ID and a timestamp and is encrypted with the session key.
4. If everything checks out, the KDC sends a session ticket back to the client that can be used to access the service in question.
5. The previous information is used to authenticate to the service, so the client accesses that service.
The basic process, without a few nuances, is depicted in Figure 14-2.
FIGURE 14-2 The Kerberos basic process
The complexity you see in Kerberos is intentional. The constant exchange of encrypted tickets and verification of information makes session hijacking far more difficult. And the combination of the session key with the TGT means an attacker would need to crack two strong encryption keys to subvert the system.
NTLM
NTLM (NT LAN Manager) is not used in modern VPNs but is commonly used in Microsoft products to provide authentication as well as other security services, and you should be familiar with it. Although Microsoft recommends Kerberos as the preferred authentication protocol, many implementations still use NTLM.
NTLM is a three-step process:
1. The client connects to the server, then sends a NEGOTIATE_MESSAGE advertising its capabilities.
2. The server responds with CHALLENGE_MESSAGE. This is used to establish the identity of the client.
3. The process culminates with the client responding to the server’s challenge with an AUTHENTICATE_MESSAGE.
Authentication in NTLM is accomplished by sending a hash of the password. NTLM version 1 uses a Data Encryption Standard (DES)–based LanMan hash. NTLM version 2 uses the MD4 cryptographic hash.
NTLM is vulnerable to the pass-the-hash attack, in which the attacker acquires a hash of the user’s password and sends that along. The attacker does not know the actual password, but has somehow acquired the hash. This can be done if the user uses the same password for a local password, so the attacker can get that hash from the local Security Account Manager (SAM) file in Windows. It may also be possible to get the hash via packet sniffing. Sometimes hashes are cached on a machine, and the attacker gets the hash from that cache. Once the attacker has the hash, she can execute the pass-the-hash attack and log in as that user without knowing the user’s password.
PPTP
Point-to-Point Tunneling Protocol is an older method whose standard was first published in 1999 as RFC 2637. The specification did not expressly define specific encryption or authentication modalities and left these up to the implementation of PPTP. The protocol has been supported in all versions of Windows since Windows 95. Originally the Microsoft implementation of PPTP used MS-CHAP for authentication and DES for encryption.
PPTP is based on the earlier Point-to-Point Protocol (PPP) and uses TCP port 1723 to establish a connection. After the initial connection is established, PPTP creates a Generic Routing Encapsulation (GRE) tunnel. The GRE protocol was developed by Cisco.
PPTP vs. PPP
Because PPTP is based on PPP, a brief description of PPP is in order. PPP was designed for moving datagrams across serial PTP links. It sends packets over a physical link—a serial cable set up between two computers. It is used to establish and configure the communications link and the network layer protocols, and also to encapsulate datagrams. PPP has several components and is actually made up of several protocols, each of which handles a different part of the process. PPP was originally developed as an encapsulation protocol for transporting IP traffic over PTP links. PPP also established a standard for a variety of related tasks, including any transfer of data from one computer to another.
PPP supports these functions by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCPs) to negotiate optional configuration parameters and facilities. In addition to IP, PPP supports other protocols. This is no longer such an advantage, however, because now all mainstream networks use TCP/IP. But at the time of the creation of PPTP, Novell used IPX/SPX, Apple used AppleTalk, and UNIX used TCP/IP. Now all of these, as well as Windows, use TCP/IP.
PPTP supports two generic types of tunneling: voluntary and compulsory. In the case of voluntary tunneling, a remote user connects to a standard PPP session that enables the user to log on to the provider’s network. The user then launches the VPN software to establish a PPTP session back to the PPTP remote-access server in the central network. This process is called voluntary tunneling because the user initiates the process and chooses whether to establish the VPN session. Although not advisable, the user could simply use a standard PPP connection without the benefits of a VPN.
In a compulsory tunneling setup, the only connection available to the host network is via a VPN. A simple PPP connection is not available—only the full PPTP connection, which forces users to use a secure connection. From a security standpoint, this is the preferred option.
PPTP Authentication
When connecting to a remote system, encrypting the data transmissions is not the only facet of security. You must also authenticate the user. PPTP supports two separate technologies for accomplishing this: EAP and CHAP. Both of these were described earlier in this chapter.
PPTP Encryption
The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE) protocol. MPPE was designed specifically for PPTP. It uses RC4 with either a 128-bit, 56-bit, or 40-bit key. Obviously, the 128-bit key is the strongest. One advantage to MPPE is that the encryption keys are frequently changed.2 During the initial negotiation and key exchange for MPPE, a bit is set to indicate what strength of RC4 to use:
128-bit encryption (S bit set)
56-bit encryption (M bit set)
40-bit encryption (L bit set)
L2TP
The Layer 2 Tunneling Protocol sends its entire packet (both payload and header) via the User Datagram Protocol (UDP). The endpoints of an L2TP tunnel are called the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). The LAC initiates a tunnel, connecting to the LNS. After the initial connection, however, communication is bilateral. Like PPTP, L2TP can work in either voluntary or compulsory tunnel mode. However, there is a third option for an L2TP multi-hop connection.
The major differences between L2TP and PPTP are listed here:
L2TP provides the functionality of PPTP, but it can work over networks other than just IP networks. PPTP can work only with IP networks. L2TP can work with Asynchronous Transfer Mode (ATM), frame relay, and other network types.
L2TP supports a variety of remote access protocols such as Terminal Access Controller Access Control System Plus (TACACS+) and Remote Authentication Dial-In User Service (RADIUS), while PPTP does not.
Although L2TP has more connection options, it does not define a specific encryption protocol. The L2TP payload is encrypted using Internet Protocol Security (IPSec). RFC 4835 specifies either Triple DES (3DES) or AES encryption. IPSec is considered far more secure that the authentication and encryption used in PPTP.3
IPSec
IPSec is probably the most widely used VPN protocol today. Unlike PPTP and L2TP, IPSec provides a complete solution that includes built-in authentication and encryption. IPSec is a security technology used in addition to IP that adds security and privacy to TCP/IP communications. IPSec is incorporated with Microsoft OSs as well as many others. For example, the security settings in the Internet Connection Firewall that ships with Windows XP enables users to turn on IPSec for transmissions. IPSec was developed by the IETF (Internet Engineering Task Force) to support secure exchange of packets. It has been deployed widely to implement VPNs.
IPSec has two encryption modes: transport and tunnel. The transport mode works by encrypting the data in each packet, but it leaves the source and destination address, as well as other header information, unencrypted. The tunnel mode encrypts both the header and the data and is more secure than transport mode but can work more slowly. At the receiving end, an IPSec-compliant device decrypts each packet. For IPSec to work, the sending and receiving devices must share a key, an indication that IPSec is a single-key encryption technology. It also comprises two other protocols beyond the two modes already described: Authentication Header (AH) and Encapsulated Security Payload (ESP).
AH is used to provide for authentication and integrity for packets. It contains several pieces of information, including payload length, an Integrity Check Value (ICV), sequence number, and Security Parameters Index (SPI). The header format is shown in Figure 14-3.
FIGURE 14-3 The Authentication Header
ESP provides confidentiality as well as authentication and integrity. The ESP header has some items similar to those of the AH. Some of the responsibilities for the two headers overlap. You can see that header in Figure 14-4.
FIGURE 14-4 The ESP header
The broad steps of the IPSec process are as follows:
1. Some party decides to initiate an IPSec VPN. That starts the Internet Key Exchange (IKE) process.
2. During IKE phase 1, the peers are authenticated and security associations are negotiated.
3. During IKE phase 2, the security association parameters are negotiated and finalized.
4. Data is transmitted.
One concept you will see regarding IPSec is that of the Security Association (SA), a set of parameters such as algorithms, keys, and other items necessary to encrypt and authenticate. One part of IPSec initiation is to ensure that both peers in an IPSec connection have identical SAs. These are established using the Internet Security Association and Key Management Protocol (ISAKMP). This protocol is most often implemented with IKE, which occurs in two phases.
IKE Phase 1
The primary purpose of the IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. In other words, after the two parties are authenticated, subsequent steps involving the exchange of keys can take place. IKE phase 1 is subdivided into a few phases:
1. Authenticates the identities of the IPSec peers
2. Negotiates a matching IKE SA policy between the peers
3. Uses Diffie-Hellman exchange so that both peers have the same secret key
Using that same secret key, the IKE phase 2 parameters can be securely exchanged.
There are two methods or modes for performing IKE phase 1: the main mode and the aggressive mode.
Main Mode
Main mode is the primary or preferred mode for IKE phase 1. In main mode, there are three two-way exchanges between the initiator and receiver.
In the first exchange, the peers agree on the symmetric algorithms used to secure communication and the cryptographic hashes used to protect integrity. This information is being exchanged via the key established using Diffie-Hellman.
In the second exchange, the two peers generate secret key material used to generate secret keys on both ends. This is similar to the process you saw for SSL/TLS in Chapter 13.
Note
The IPSec standard allows for HMAC, SHA1, and SHA2 to be used for authentication and 3DES and AES (both with cipher-block chaining) to be used for encryption.
The third exchange involves each peer verifying the other’s identity. At the end of this exchange, the two peers should have identical SAs, and a secure channel exists between the two peers.
Aggressive Mode
Aggressive mode essentially condenses the process of main mode into fewer exchanges. The entire process is condensed into just three packets. All of the information required for the SA is passed by the initiating peer. The responding peer then sends the proposal, key material, and ID, and authenticates the session in the next packet. The initiating peer then replies by authenticating the session. And at that point IKE phase 1 is complete.
IKE Phase 2
You may think that after IKE phase 1 there is nothing left to do. However, IPSec takes additional steps to ensure that communication is secure and authenticated. IKE phase 2 has only one mode, called quick mode, which occurs immediately after IKE phase 1 is complete.
Phase 2 negotiates a shared IPSec policy and then derives secret keying material used for the IPSec security algorithms. Phase 2 also exchanges nonces (Numbers Only used oNCE) that provide protection against a variety of attacks, including replay attacks. The nonces are also used to generate new secret key material and prevent replay attacks. IKE phase 2 can also be used to renegotiate new SAs if the IPSec SA lifetime expires but the peers have not terminated communication.
The basic flow of these phases is shown in Figure 14-5.
FIGURE 14-5 IKE phases 1 and 2
Note
During establishment of IPSec policies, if a setting called Perfect Forward Secrecy is specified in the IPSec policy, then a new Diffie-Hellman exchange is performed with each iteration of IKE phase 2 quick mode. This means new key material is used each time IKE phase 2 is executed.
Although IKE is the most common way to set up SAs, there are other methods, including IPSECKEY DNS records and Kerberized Internet Negotiation of Keys (KINK).
SSL/TLS
A new type of firewall uses Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to provide VPN access through a web portal. Essentially, TLS and SSL are the protocols used to secure web sites. Web site URLs beginning with HTTPS indicate that traffic to and from that site is encrypted using SSL or TLS.
In some VPN solutions, the user simply logs in to a web site that is secured with SSL or TLS, and is then given access to a VPN. It is important that you know that simply visiting a web site that uses SSL or TLS does not mean you are on a VPN. As a general rule, most web sites, such as banking web sites, give you access only to a very limited set of data, such as your account balances. A VPN gives you access to the network—the same or similar access to what you would have if you were physically on that network.
The process to connect, authenticate, and establish the VPN is the same as that described in Chapter 13. The difference is that instead of simply getting secure access to a web site such as a bank or e-commerce site, the end user gets a VPN connection to their network.
Other Secure Communications
A variety of additional secure communications are not considered VPNs, but they do use authentication and encryption to provide secure communication with some endpoint. SSL/TLS communication with a secure web site, described in Chapter 13, would be the most common example of such a communication. In this section, we will look at a few additional communication methods.
SSH
It is common for network administrators to need to use some secure communication channel to access a server. Telnet has long been used for this purpose: however, Telnet sends the data in clear text and is thus insecure. The only way to secure Telnet is to establish a VPN and then connect via Telnet through the VPN. SSH provides an alternative that is secure, without the need to establish a VPN first.
UNIX and UNIX-based systems such as Linux use SSH to connect to a target server. The SSH standard uses asymmetric cryptography to authenticate the remote computer and, when mutual authentication is required, to authenticate the client. SSH was first released in 1995 and was developed by Tatu Ylonen at Helsinki University of Technology. His goal was to replace insecure protocols such as Telnet, Remote Shell (RSH), and rlogin. SSH version 1 was released as freeware. By 1999, OpenSSH had been released and is still a very popular version of SSH.
SSH version 2 has an internal architecture with specific layers responsible for particular functions:
Transport layer Handles the key exchange and authentication of the server. Keys are re-exchanged usually after either 1 hour of time has passed or 1GB of data has been transmitted. This re-negotiation of keys is a significant strength of SSH.
User authentication layer Authenticates the client, usually via password and public key. The password method checks the user’s password. The public key method uses either Digital Signature Algorithm (DSA) or RSA key pairs to verify the client’s identity, and can also support X.509 certificates.
Generic Security Service Application Program Interface (GSSAPI) authentication is a variation of SSH authentication that allows for the use of either Kerberos or NTLM to authenticate. Although not all versions of SSH support GSSAPI, OpenSSH does.
SSH can be used to provide secure file transfer with technologies such as Secure Copy Protocol (SCP), SSH File Transfer Protocol (SFTP), and Files transferred over Shell Protocol (FISH).
SSH can be configured to use several different symmetric algorithms including AES, Blowfish, 3DES, CAST-128, and RC4. The specific algorithm is configured for each SSH implementation.
Wi-Fi Encryption
One obvious application of cryptography is encrypting wireless communications. Wi-Fi is now ubiquitous. Most homes in North America, Europe, Japan, and much of the world use wireless Internet. Free Wi-Fi can be found at bars, coffee shops, airports, fast food restaurants, and other locations. For a fee, you can even access Wi-Fi in flight on many airlines. The pervasiveness of Wi-Fi means that securing wireless communications is critical.
WEP
Wired Equivalent Privacy was released in 1999. It uses RC4 to encrypt the data and a CRC-32 checksum for error checking. Standard WEP uses a 40-bit key (known as WEP-40) with a 24-bit initialization vector to form 64-bit encryption; 128-bit WEP uses a 104-bit key with a 24-bit initialization vector (IV).
Because RC4 is a stream cipher, the same traffic key must never be used twice. The purpose of an IV, which is transmitted as plain text, is to prevent any repetition, but a 24-bit IV is not long enough to ensure this on a busy network. The IV must never be repeated (recall the concept of a number used only once).
In August 2001, Scott Fluhrer, Itsik Mantin, and Adi Shamir published a cryptanalysis of WEP. They showed that because of the improper implementation of RC4 along with the reuse of initialization vectors, WEP could be cracked with relative ease.
WEP should never be used today unless there is absolutely no other choice. However, the story of WEP illuminates one reason more security professionals need to understand cryptography (and thus the reason I wrote this book). WEP was created by a consortium of computer companies, each contributing engineers to work on the standard. Clearly these were skilled engineers with a solid understanding of network communications—however, they lacked an appropriate knowledge of cryptography and this led to an insecure wireless encryption standard.
WPA
Wi-Fi Protected Access was released in 2003 and was intended as an intermediate step to make up for the issues with WEP while the full implementation of 802.11i (WPA2) was being finalized. One advantage of WPA over WEP is the use of the Temporal Key Integrity Protocol (TKIP), a 128-bit per-packet key that generates a new key for each packet. This regeneration of keys makes WPA much stronger than WEP.
Note
802.11 is the IEEE standard for wireless communications. If you have an “N” router, what you really have is a router that complies with the 802.11n wireless standard. 802.11i is the IEEE standard for wireless security.
WPA operates in one of two modes:
WPA-Personal Also referred to as WPA-PSK (pre-shared key) mode, WPA-Personal is designed for home and small office networks and doesn’t require an authentication server. Each wireless network device authenticates with the access point using the same 256-bit key.
WPA-Enterprise Also referred to as WPA-802.1x mode, WPA-Enterprise is designed for enterprise networks and requires a RADIUS authentication server. EAP is used for authentication. EAP has a variety of implementations such as EAP-TLS and EAP-TTLS.
WPA2
WPA2 is the only Wi-Fi encryption protocol that fully implements the IEEE 802.11i standard. It uses a robust set of cryptographic algorithms. Confidentiality is maintained through the use of AES using cipher-block chaining (CBC). Message integrity is protected via message authentication codes (MACs).
WPA2 allows for the optional use of Pairwise Master Key (PMK) caching and opportunistic PMK caching. In PMK caching, wireless clients and wireless access points (WAP) cache the results of 802.1X authentications. This improves access time.
The optional use of pre-authentication allows a WPA2 wireless client to perform an 802.1X authentication with other wireless access points in its range, even though it is still connected to the current WAP. This also speeds connectivity.
In modern Wi-Fi systems, you should always select WPA2 unless you have a compelling reason to use one of the other Wi-Fi protocols. In some cases, you may need to support older systems that cannot perform WPA2.
Conclusions
The point of this and the preceding chapter is to demonstrate common applications of the cryptography you have been studying throughout this book. There are two sides to cryptography: The first is the understanding of the mathematics and algorithms being used to secure communications; the second is to have a working knowledge of the protocols that implement these cryptographic algorithms.
In this chapter we explored some of the most common applications of cryptography, in particular VPNs. You must understand the authentication methods as well as the VPN protocols presented. Most important are CHAP, Kerberos, L2TP, and IPSec. You were also introduced to other applications of cryptography such as Secure Shell (SSH) and Wi-Fi encryption. Both of these are common applications of the cryptographic algorithms you have learned previously in this book.
Test Your Knowledge
1. What is a Kerberos principal?
2. To what attack is NTLM particularly susceptible?
3. The IPSec standard describes three algorithms used for integrity. What are they?
4. What phase of IPSec involves the exchange of nonces?
5. What authentication protocols does PPTP use?
6. Which authentication method is based on periodically re-requesting a hash from the client?
7. How many steps are in IKE phase 1 in aggressive mode?
8. What encryption does PPTP use?
9. What is the major weakness in WEP?
10. Which Wi-Fi encryption protocol completely implements 802.11i?
Answers
1. Any user or computer to whom tickets can be assigned
2. Pass-the-hash
3. HMAC, SHA1, and SHA2
4. IKE phase 2
5. CHAP and EAP
6. CHAP
7. Three
8. MPPE
9. Reusing initialization vectors
10. WPA2
Endnotes
1. D. Downing, M. Covington, and C. Covington, Dictionary of Computer and Internet Terms, 10th Ed. (Barron’s Educational Series, 2009).
2. G. Pall and G. Zorn, “Microsoft Point-to-Point Encryption (MPPE) Protocol,” RFC 3078, www.ietf.org/rfc/rfc3078.txt.
3. IVPN, “PPTP vs. L2TP/IPSec vs. OpenVPN,” www.ivpn.net/pptp-vs-l2tp-vs-openvpn.