VPN Protocols
VPN Protocols
VPN Protocols
Multiple ways exist to achieve the encryption needs of a VPN. Certain network
protocols are frequently used for VPNs. The two most commonly used protocols
for this purpose are Point-to-Point Tunnelling Protocol (PPTP) and Layer 2
Tunnelling Protocol (L2TP). The part of the connection in which the data is
encapsulated is referred to as the tunnel. L2TP is often combined with IPSec to
achieve a high level of security.
6.2.1 PPTP
PPTP was originally proposed as a standard in 1996 by the PPTP Forum—a group
of companies that included Ascend Communications, ECI Telematics, Microsoft,
3Com, and U.S. Robotics. This group’s purpose was to design a protocol that
would allow remote users to communicate securely over the Internet.
Although newer VPN protocols are available, PPTP is still widely used, because
almost all VPN equipment vendors support PPTP. Another important benefit of
PPTP is that it operates at layer 2 of the OSI model (the data link layer), allowing
different networking protocols to run over a PPTP tunnel.
When connecting users 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: Extensible Authentication Protocol
(EAP) and Challenge Handshake Authentication Protocol (CHAP).
EAP was designed specifically with PPTP and is meant to work as part of PPP.
EAP works from within PPP’s authentication protocol. It provides a framework for
several different authentication methods. EAP is meant to supplant proprietary
authentication systems and includes a variety of authentication methods to be used,
including passwords, challenge-response tokens, and public key infrastructure
certificates.
6.2.2 L2TP
Like PPTP, L2TP supports EAP and CHAP. However, it also offers support for
other authentication methods, for a total of six:
EAP
CHAP
MS-CHAP
PAP
SPAP
Kerberos
6.2.2.1 MS-CHAP
6.2.2.2 PAP
6.2.2.3 SPAP
6.2.2.4 Kerberos
Kerberos works by sending messages back and forth between the client and the
server. The actual password (or even a hash of the password) is never sent. That
makes it impossible for someone to intercept it. What happens instead is that the
username is sent. The server then looks up the stored hash of that password, and
uses that as an encryption key to encrypt data and send it back to the client. The
client then takes the password the user entered, and uses that as a key to decrypt
the data. If the user entered the wrong password, then it will never get decrypted.
This is a clever way to verify the password without ever being transmitted.
Authentication happens with UDP (User Datagram Protocol) on port 88.
After the user’s username is sent to the authentication service (AS), that AS will
use the hash of the user password that is stored as a secret key to encrypt the
following two messages that get sent to the client:
Remember, both of these messages are encrypted using the key the AS generated.
Then the user attempts to decrypt message A with the secret key generated by the
client hashing the user’s entered password. If that entered password does not match
the password the AS found in the database, then the hashes won’t match, and the
decryption won’t work. If it does work, then message A contains the Client/TGS
session key that can be used for communication with the TGS. Message B is
encrypted with the TGS secret key and cannot be decrypted by the client.
Now the user is authenticated into the system. However, when the user actually
requests a service, some more message communication is required. When
requesting services, the client sends the following messages to the TGS:
Upon receiving messages E and F from TGS, the client has enough information to
authenticate itself to the Service Server (SS). The client connects to the SS and
sends the following two messages:
The SS decrypts the ticket (message E) using its own secret key to retrieve the
client/server session key. Using the session key, the SS decrypts the Authenticator
and sends the following message to the client to confirm its identity and
willingness to serve the client:
The client decrypts the confirmation (message H) using the client/server session
key and checks whether the timestamp is correct. If so, then the client can trust the
server and can start issuing service requests to the server. The server provides the
requested services to the client.
Realm: A boundary within an organisation. Each realm has its own AS and TGS.