13.3 POINT-TO-POINT TUNNELING PROTOCOL

Team-Fly

Similar to the L2F protocol, the Point-to-Point Tunneling Protocol (PPTP) was originally developed and designed to solve the problem of creating and maintaining VPN tunnels over public TCP/IP-based networks using the PPP [6, 7].^[4] The PPTP is the result of joint efforts of Microsoft and a set of product vendors, including, for example, Ascend Communications, 3Com/Primary Access, ECI Telematics, and U.S. Robotics. These companies originally constituted the PPTP Forum, whose resulting PPTP specification was made publicly available and submitted to the IETF Point-to-Point Protocol Extensions (PPPEXT^[5]) WG for possible consideration as an Internet Standard in 1996.^[6] PPTP is documented in a series of Internet-Drafts^[7] that have all since expired.

As illustrated in Figures 13.1 and 13.3, a typical deployment of the PPTP would start with a remote system or dial-up client, such as a laptop computer, that must be interconnected to an LNS located on a corporate intranet using an LAC. As such, the PPTP can be used to encapsulate PPP frames in IP packets for transmission over the Internet or any other publicly accessible TCP/IP-based network. More specifically, the remote system can connect to the LNS in two ways:

Directly using the PPTP (if the remote system supports PPTP);
Using an Internet service provider's LAC that supports inbound PPP connections (if the remote system does not directly support the PPTP).

In the first case, the situation is comparably simple. The remote system first establishes a PPP connection to the Internet service provider's LAC and then uses PPTP to send encapsulated PPP frames to the LNS. The IP packets that encapsulate the PPP frames are simply forwarded by the LAC.

In the second case, however, the situation is more complicated. In this case, the LAC must use the PPTP to encapsulate the PPP frames in IP packets on behalf of the remote system. Consequently, the LAC must play the role of an intermediate or proxy server in one way or another. In fact, there are two connections. The first connection uses the PPP to interconnect the remote system and the LAC, whereas the second connection uses the PPTP to interconnect the LAC and the LNS. PPP frames received by the LAC are encapsulated in IP packets using the PPTP.

In either case, the PPTP uses a sophisticated encapsulation scheme to tunnel PPP frames through the Internet (or any other TCP/IP-based network that interconnects the LAC and the LNS). As illustrated in Figure 13.4, network or Internet layer protocol data units (e.g., IP packets, IPX packets, or NetBEUI messages) are first framed using PPP. The resulting PPP frames are then encapsulated using a generic routing encapsulation (GRE) header [8] as well as an IP header that is used to route the frame through the Internet. Finally, the resulting IP packets are framed with still another media-specific header before they can be forwarded to the interface connected to the Internet (the media-specific header is not even illustrated in Figure 13.4).

click to expand
Figure 13.4: The PPTP encapsulation scheme.

In addition to the data channel that uses IP encapsulation to transmit data, the PPTP uses a TCP connection for signaling. The corresponding messages that are sent or received over this connection are used to query status and to convey signaling information between the LAC (i.e., the PPTP client) and the LNS (i.e., the PPTP server). The control channel is always initiated by the PPTP client to the PPTP server using TCP port number 1723. In most cases, it is a bidirectional channel where the client can send messages to the server and vice versa. Note that the notion of an outband signaling channel is something very specific for PPTP. Most other security protocols (e.g., the IPsec protocols) use inband signaling, meaning that signaling information is transported together with the protected data units.

The PPTP specification does not mandate the use of specific algorithms for authentication and encryption. Instead, it provides a framework for the negotiation of particular algorithms. This negotiation is not specific to PPTP, and relies on existing PPP option negotiations contained within the PPP compression protocol (CCP) [9], the challenge handshake authentication protocol (CHAP) [10], and some other PPP extensions and enhancements. Also outside the world of the PPTP, PPP sessions have been able to negotiate compression algorithms as well as authentication and encryption algorithms [11, 12].

In spite of the fact that the PPTP specification was submitted to the IETF PPPEXT WG for consideration as an Internet Standard, its standardization effort has been abandoned. It is currently available only for networks served by Windows NT 4.0 or the Linux operating systems. This is not likely to change in the future, as most vendors move to the L2TP as a replacement for the PPTP. Against this background, Microsoft's implementation of the PPTP (i.e., MS-PPTP) is still the most widely deployed protocol for virtual private networking and providing VPN connectivity. It is part of the Windows NT server software distribution and is also used extensively in other VPN products. The Microsoft PPTP server only runs under Windows NT, whereas the client software is also available for Windows 95 and Windows 98 (and probably all future releases of the Windows operating systems). Configuration issues are fully addressed in Chapter 6 of [6]. They are not covered in this book. In the rest of this section, we focus on the security properties of MS-PPTP. Keep in mind, however, that the PPTP is somehow outdated and that the industry is steadily replacing both the L2F protocol and PPTP with L2TP.

13.3.1 MS-PPTP Authentication

MS-PPTP currently supports three authentication methods:

Clear password. The client authenticates to the server by sending it a password in the clear.
Hashed password. The client authenticates to the server by sending it a one-way hash value of the password.
Challenge-response. The client and the server authenticate each other using MS-CHAP [13], which is Microsoft's version of the commonly used CHAP [10].

For obvious reasons, the clear password authentication option (i.e., clear password) is susceptible to password sniffing and cannot be considered to be secure. In regard to the hashed password authentication option (i.e., hashed password), Microsoft's implementation of PPTP for Windows NT actually uses two one-way hash functions: the LAN Manager hash function^[8] and the Windows NT hash function^[9]:

The LAN Manager hash function is based on the DES encryption algorithm. It basically works as follows:
1. The password is turned into a 14-character string, either by truncating longer passwords or padding shorter passwords with zeros.
2. All lowercase characters are converted to uppercase (numbers and non-alphanumeric characters remain unaffected).
3. The 14-byte string is split into two 7-byte strings, and a fixed constant is DES-encrypted using each 7-byte string as a key. Consequently, this step yields two 8-byte encrypted strings.
4. The two resulting 8-byte encrypted strings are concatenated to create a single 16-byte hash value.
Contrary to that, the Windows NT hash function is based on the MD4 one-way hash function. It basically works in two steps:
1. The password (up to 14 characters long and case-sensitive) is converted to Unicode.
2. The password is hashed using the MD4 one-way hash function, yielding a 16-byte hash value.

For obvious reasons, dictionary attacks are possible and quite easy to be launched to break the security of the LAN Manager hash function.^[10] The Windows NT hash function is an improvement over the LAN Manager hash function, because case sensitivity provides more entropy for the passwords, passwords can be longer than 14 characters, and hashing the entire password together instead of in small sections is better. However, neither of the two hash functions provides support for a salt mechanism, such as is employed, for example, by the UNIX and Linux operating systems.^[11] Consequently, two people with the same password will always have the same LAN Manager and Windows NT hash values, so comparing a file of hashed passwords with a precomputed dictionary of hashed password candidates is still a fruitful attack. Also note that both hash values are always sent together. Therefore, it is possible to brute-force the password using the weaker hash function (i.e., the LAN Manager hash function), and then test various lowercase alternatives to actually find the other hash value (i.e., the Windows NT hash value). In fact, Peter Mudge developed a software called Lophtcrack to automate the process of recovering passwords from their corresponding hash values. Today, the tool is widely deployed on the Internet and it is being marketed by Security Software Technologies, Inc.^[12]

When using MS-CHAP [13], the challenge-response option of MS-PPTP authentication, the client first requests a login challenge, and the server sends back an 8-byte random challenge. The client then calculates the LAN Manager hash value, adds five zero-bytes to create a 21-byte string, and partitions the string into three 7-byte keys. Each key is then used to encrypt the challenge with the DES encryption algorithm, resulting in a 24-byte encrypted string. This string is sent to the server as a response. In addition, the client does the same with the Windows NT hash functions, resulting in another 24-byte encrypted string. The server, in turn, looks up one of the two hash values in its local database, reconstructs the three DES keys, encrypts the challenge with these keys, and compares the results with the encrypted hash values it has received from the client. If all three values match, the authentication process is successful. Note that, in principle, the server could make the comparison on the LAN Manager or Windows NT hash value. In either case, the result should be the same. Which hash value the server should use depends on a flag set in the client's response message. If the flag is set, the server tests against the Windows NT hash value; if the flag is not set, the server tests against the LAN Manager hash value.

In either case, MS-CHAP must be used for subsequent PPTP data traffic to be encrypted. With either of the other two authentication options (clear or hashed password), no encryption is available in MS-PPTP.

13.3.2 MS-PPTP Encryption

In addition to the various PPTP authentication options, the Microsoft Point-to-Point Encryption (MPPE) protocol makes it possible to encrypt PPTP data traffic [14]. In short, the MPPE protocol assumes the existence of a secret key that is shared between a client and a server and then uses the RC4 stream cipher to transparently encrypt the data traffic between them. In the past, there was a U.S. domestic version and an international version of MS-PPTP encryption (the U.S. domestic version used 128-bit keys, whereas the international version was restricted to 40-bit keys). Again, this distinction no longer applies and it is now possible to also use strong cryptography (i.e., long keys) outside the United States and Canada.

One question that arises immediately is how the client and the server come into possession of a shared secret key. One possibility would be to use the outband signaling channel to perform a Diffie-Hellman key exchange and to subsequently authenticate this key exchange using digital signatures. As discussed in Chapter 14, this approach is similar to the key exchange mechanism used for the IPsec protocols. The developers of the MPPE, however, traded security against efficiency and came up with a much simpler scheme (as discussed later, the scheme is actually too simple to provide a sufficient level of security).

A 40-bit RC4 key was generated by first generating a deterministic 64-bit key from the LAN Manager hash value of the user's password using SHA-1, and then setting the high-order 24 bits of the key to OxD1269E.^[13]
Similarly, a 128-bit RC4 key was generated by first concatenating the Windows NT hash value of the user's password and a 64-bit random nonce created by the server during the execution of MS-CHAP, and then generating a deterministic 128-bit key again using SHA-1.

In either case, the resulting key was used to initialize the RC4 stream cipher in the usual manner, and then to encrypt the data stream. After every 256 packets, a new RC4 key—64 bits long for 40-bit encryption and 128 bits long for 128-bit encryption—was generated by hashing the previous key and the original key with SHA-1. Again, if the required key was 40 bits, the high-order 24 bits of the key were set to the hexadecimal value mentioned above.

13.3.3 Security Analysis

In 1998, Bruce Schneier and Peter Mudge cryptanalyzed the first version of MS-PPTP [15]. In summary, they found this version of MS-CHAP to be weak and easily susceptible to dictionary attacks. For example, one problem stems from the fact that the LAN Manager and the Windows NT hash values are both transmitted (even in a Windows NT-only environment), and that it is therefore possible to attack the weaker hash function (i.e., the LAN Manager hash function). Another problem with MS-CHAP is that only the client is authenticated. Consequently, an attacker who hijacks a connection can easily masquerade as the server. If encryption is enabled, the attacker will not be able to send and receive messages (unless he or she also breaks the encryption), but by reusing an old challenge value, he or she can obtain two sessions encrypted with the same key. This can be further explored by the attacker to break the encryption.

With regard to the MPPE protocol, the situation is even worse. It is important to note that the RC4 key is deterministically derived from the hash value of the user password. Consequently, the security of the key is no greater than the security of the password. In other words, the entropy of the key is bounded by the entropy of the password.^[14] To make things worse, the 40-bit RC4 encryption suffers from even more serious weaknesses. Because there is no salt mechanism,^[15] an attacker can precompute a dictionary of ciphertext headers and then quickly look up a given ciphertext in this dictionary. Moreover, the same 40-bit RC4 key is generated every time a user initializes PPTP. Because RC4 is an output feedback (OFB) mode stream cipher, it is possible to break the encryption from the ciphertext from two sessions. Unfortunately, the same key is used in both the forward and backward direction, guaranteeing that the same keystream is used to encrypt two different plaintexts. The 128-bit RC4 encryption uses a 64-bit nonce in the key generation process, making precomputed dictionary attacks impractical. Nevertheless, brute-force attacks against the password are still much more efficient than brute-force attacks against the keyspace. The use of the nonce also means that two sessions using the same password will have two different 128-bit RC4 keys, although the same key will be used to encrypt the plaintext in both directions. Remember that RC4 is an OFB mode stream cipher, and that MPPE does not provide authentication and integrity of the ciphertext stream. Consequently, an attacker can undetectably flip arbitrary bits in the ciphertext stream and compromise the integrity of the data stream accordingly. This attack does not require the attacker to know the secret key or the client's password (of course, higher-level protocols might detect or prevent these sorts of attacks).

In addition to the attacks against MS-CHAP and the MPPE protocol, Schneier and Mudge also showed how an attacker can either spoof resynchronization requests or forge MPPE packets with incorrect coherency counts. If this is done continuously just before the 256th packet exchange, in which the session key would normally be updated, an attacker can succeed in forcing the encrypted communications channel to never rekey. In addition, they described a number of other attacks against MS-PPTP, including, for example, passive monitoring of PPTP servers, spoofing PPP negotiation parameters, and several denial-of-service attacks against the server.

In June 1998, Microsoft posted a preliminary answer to the security problems. In fact, they argued that for reasons of legacy compatibility, Microsoft had continued to support both the LAN Manager and the Windows NT hash function in its PPTP implementation, and that future releases of PPTP software would provide administrators with the ability to configure a PPTP server so that it would only accept the cryptographically stronger Windows NT hash function. With regard to the problem of having the session keys derived from the password's hash, Microsoft recommended the use of 128-bit encryption and that administrators enforce the use of strong passwords.

More recently, Microsoft released an upgrade for its MS-PPTP implementation. Commonly referred to as MS-PPTP version 2, or as MS-PPTP V2, several improvements were made. For example, MS-CHAP was upgraded to something similar to, but incompatible with, MS-CHAP version 1 [16]. Also, MS-PPTP V2 uses a unique key in either direction to make certain cryptanalytical attacks more difficult (the keys for each direction are still derived from the same value, the user's password Windows NT hash value, but differently depending on the direction). Furthermore, the LAN Manager hash value of the user's password is no longer sent along with the stronger Windows NT hash value. Unfortunately (and because of the lack of a salt mechanism for password hashing), MS-PPTP V2 is still vulnerable to offline password-guessing attacks, such as employed by L0phtcrack. Furthermore, version rollback attacks are possible to invoke the cryptanalytically weaker MS-CHAP V1 and to attack the user's LAN Manager hash value accordingly. Refer to [17] for a more comprehensive security analysis of MS-PPTP V2. The paper is electronically available on-line.^[16]

^[4]http://www.microsoft.com/technet/winnt/winntas/technote/pptpudst.asp

^[5]http://www.ietf.org/html.charters/pppext-charter.html

^[6]Note that the IETF PPPEXT WG is situated in the IETF's Internet area (not in the security area).

^[7]draft-ietf-pppext-pptp-*.txt

^[8]The LAN Manager hash function was originally developed by Microsoft for IBM's OS/2 operating system, and was later integrated into Windows for Workgroups and optionally in Windows 3.1.

^[9]The Windows NT hash function was developed by Microsoft specifically for Windows NT.

^[10]Note that all characters are converted to uppercase, making the number of possible passwords smaller. Also, there is no salt mechanism (as addressed in the following footnote), causing two users with the same password to always have the same hashed password. Finally, the two 7-byte halves of the password are hashed independently, enabling the two halves to be attacked with brute force independently.

^[11]In many operating systems, user passwords are stored in the one-way encrypted form. The one-way function that is used for this transformation is publicly known, so anybody could generate a codebook with password candidates transformed with this one-way function. In order to make it more difficult to generate such a codebook, the UNIX operating system uses a salt mechanism. The basic idea is to use a random number (which is also called "salt" or "salt value") as a parameter for the one-way function, and to store the salt as cleartext in the password file (together with the one-way encrypted password). When the operating system wants to check the user-supplied password, it has to feed the one-way function with the appropriate salt value (the one it reads from the password file). As a consequence, an attacker can only launch a dictionary attack against a specific salt value, and a dictionary attack against the entire set of users is no longer possible (or at least more difficult).

^[12]http://www.securitysoftwaretech.com/10phtcrack/

^[13]The MPPE protocol specification includes a flag for calculating the 40-bit RC4 key based on the Windows NT hash instead of the LAN Manager hash, but this feature was not implemented in the first version of MPPE.

^[14]In information theory, the entropy of a random variable X measures the amount of information provided by an observation of X. Equivalently, it is also the uncertainty about the outcome before an observation of X. Entropy is particularly useful for approximating the average number of bits required to encode the elements of X. For example, the English language has about 1.3 bits of entropy per character, and case variations, numbers, and nonalphanumeric characters increase this value significantly.

^[15]The rationale behind the salt mechanism is explained in footnote 8.

^[16]http://www.counterpane.com/pptpv2-paper.html

Team-Fly