White Paper: The Achilles heel of VPNs: the man-in-the-middle-attack

Authenticating identity is the most crucial security question for virtual private networks

Authenticating identity is the most crucial security question for virtual private networks

Virtual private networks

The vulnerability of VPNs

Common authentication of identity solutions

Authentication servers and usernames/passwords


Digital signatures


Digital certificates

Certificate authorities

Guidelines for authentication of identity


Compiled by Mike Burkitt

(c) 1999 OneBOX Networks

A Virtual Private Network (VPN) refers to use of public networks to carry secure private information between intra-company locations (intranets) or inter-company locations (extranets). A VPN can be built on the Internet or on a network service provider's IP, frame relay or ATM infrastructure. VPNs based on IP extend intranets over wide area links to remote offices, to mobile users or to telecommuters. Furthermore, they extend extranets, linking business partners', customers and suppliers to provide better customer satisfaction and reduced manufacturing costs. Alternatively, they connect communities of interest, providing a secure forum for common topics of discussion. In the world of data transmission, the most serious security threats occur within the Wide Area Network (WAN). Hackers can easily intercept, alter or delete important data with little danger of detection. For example, Paula sends Clive a letter through the post. Paula's letter bears Clive's destination address on the front and her source address on the back. An intruder intercepts the letter from Paula and changes Clive's original source address to the intruders source address and then forwards it to Clive. When Clive replies to Paula, he unknowingly places the intruder's destination address on the front of the letter and his own source address on the back. Again, the sneaky intruder intercepts the letter, removes his own destination address from the front of the letter and replaces it with Paula's source address. When Clive receives the letter he assumes that Paula actually sent the letter. Likewise, when Paula receives Clive's response, she is certain that Clive actually sent it. This is the issue of identity. Now, suppose we increase the complexity of the problem by having our intruder actually open the letters between Clive and Paula and alter the informational content. Clive not only believes that Paula sent the letter, he assumes she wrote it and vice-versa. This is the issue of integrity, or the alteration of information in transit between source and destination. Together, these two issues constitute "man-in-the-middle-attack" and point out the need to validate the identity and integrity of the data. Let's examine several common methods of authenticating identity and then decide whether they actually achieve what they claim. Authentication of identity is often carried out within a RADIUS server or TACACS server. The basic material for authentication of identity within RADIUS or TACACS is the username attribute and optional password attribute. The actual basic identity material (username and password) may be ascertained through protocols such as Point to Point Protocol (PPP) or Serial Line Internet Protocol (SLIP). For example, within Windows 95 dial up networking, a user enters a username and optional password prior to dialling. The dial access is essentially characterised by a user initiating either a PSTN modem or ISDN terminal adaptor call from the PPP client. The PSTN or ISDN call is then terminated within a Network Access Server (NAS) or a Remote Access Server (RAS) and the PPP is also terminated. This allows the NAS or the RAS to send the basic identity material (username and password) to the RADIUS or TACACS sever. The NAS is typically located within a service provider's network where authentication of identity is carried out. The RAS is typically located within the enterprise and this is where authentication of identity is carried out. The RADIUS or TACACS server database is configured with the user information to be authenticated. The basic identity material (username and password) is then validated against entries within the pre-configured database. If a match is found, then authentication of identity has been established and the server will then authorise user access. This is an extremely weak form of authentication of identity. Firstly, there is no real guarantee of the "true" identity of the user. The user could actually be anyone just entering a valid username and password. Secondly, the solution lends itself to allowing multiple concurrent users all with same username and password which clearly indicates the lack of identity within the solution. Thirdly, this solution is wide open to "man-in-the-middle-attack". You never really know if the claimed sender of the basic identity material (username and password) is in fact the actual sender and, even if the user identity has been authenticated, there is no continued challenge of identity. Admittedly, Challenge Handshake Access Protocol (CHAP) allows for some degree of continued challenge of identity, but all you ever get back from the RAS or NAS is the same basic identity material (username and password) which is fundamentally inadequate. The weakness of this form of authentication of identity rests in the poor basic identity material and the real lack of continued challenge of identity. There are two distinct types of tokens. One type of token is a PC Card compatible portable hardware device consisting of an integrated circuit card with a microprocessor and memory sealed in a tamper-resistant module. The token functions as a portable, isolated, personal identity engine. The other type is a credit card-size portable piece of hardware consisting of an integrated circuit card with a microprocessor and memory, sealed in a tamper-resistant module, but not PC compatible. Access to a token's services requires both a Personal Identification Number (PIN) and the physical possession of the token. In order for an attacker to compromise such an authentication, he must compromise two dissimilar types of authentication, an attack much riskier and more complicated than the theft of a password. For this reason, two-factor authentication of identity is widely considered to be much more secure than the single factor authentication of a password alone. Tokens can be thought of as one-time passwords providing some degree of identity for an individual. Tokens provide a higher level of proof than simple username and password entry. Tokens are often delivered through the RADIUS or TACACS protocol to a separate security server to authenticate identity. However, the weakness in this form of authentication of identity resides in the poor basic identity material and the real lack of continued challenge of identity. Token solutions, in isolation, are unable to combat "man-in-the-middle-attack". Digital signatures essentially are derived through public key cryptography. Rather than using the same key to encrypt and decrypt data, the public key cryptography system uses a matched pair of encryption and decryption keys. Each key performs a one way transformation upon the data. The public key encrypts data whilst the private key decrypts data. When a "message" is encrypted with a private key, it provides the basis for a "digital signature", a scrambled message that only one person could produce, but everyone could verify with the person's public key. Furthermore, the private key is never ever sent across the WAN, therefore it can never be exposed to an intruder. The "message" to be encrypted with the private key is often a message digest. Hand-written signatures do more than just identify the author of a document, in effect, they must vouch for the document's integrity. Within VPNs, integrity is the property of ensuring that data is transmitted from source to destination without undetected alteration. A digital signature employs a cryptographic "hashing" algorithm to create a message digest that is unique to each document, much like a fingerprint. If even a single bit of the document is changed, roughly 50 per cent of the bits in the corresponding message digest will change. And the hashing algorithm is a one-way function: the document content cannot be reconstructed from the bits of the message digest. With the SHA-1 secure hash algorithm, or others such as MD5, the probability that different documents will have the same digest by coincidence is less than 1 in a trillion, effectively ensuring that two message digests will only match if their source documents are bit for bit identical. So while Digital Signatures are easy to produce and check, they are impossible to forge and positively identifies the author. And, unlike a hand-written signature, they also verify the contents of a document. Digital signatures provide a stronger method of authentication of identity than the previous authentication server and token solutions. However, the solution is still prone to the "man-in-the-middle-attack" We have already stated that the private key is never exposed to an intruder, it is never sent across the WAN. However, an intruder could change some real public keys with his or her own public key if they are sent across the WAN. Today's secure communications rely on public key technology, and in this environment, the authenticity of a public key is crucial. Without solid assurance that a public key belongs to the person or organisation it represents, one might unknowingly transmit secret information directly into the hands of an impostor or accept that impostor's digital signature as authorisation for a critical electronic business transaction. A digital certificate is essentially a "digital ID" that notarises the connection between the public key and its legitimate owner. This notarisation is validated by a trusted third party, the Certification Authority (CA). Public keys are bound to individuals through digital certificates distributed by a certifying authority hierarchy. Such a trusted binding is accomplished as follows: Paula presents identification to a CA, a designated individual presumed to be both wise and honest, and requests a key pair. The CA, convinced of Paula's identity, prepares a digital certificate consisting of her identification and public key, which he then digitally signs with his private key. Since her identity and public key are now bound together under the certification of the CA, the binding of Paula to her public key is validated by the trust placed in the binding of the CA to its public key. This is in turn validated in a similar fashion by the trust placed in the binding of his CA, standing above him in the CA hierarchy, to her public key, and so on up the hierarchy chain. The parties retrieve each other's digital certificate and authenticate it using the public key of the issuing certification authority. They have confidence that the public keys are real, because a trusted third party vouches for them. The ITU-T X.509 Digital Certificate is the internationally recognised document used to prove identity and public key ownership over a communications network. Each certificate contains the issuer's name, the user's public key and identifying information, and the issuer's digital signature. The signature, which validates the certificate, also "seals" the certificate so that it can't be forged or altered. Digital certificates provide the strongest method to authenticate identity. The primary attacks aimed at obtaining a false public key certificate are, fooling or coercing the CA, essentially a problem in social engineering or compromising the CA's private key. Here, the problem returns to that of protecting the private key. An example of bad key management practice would be for Clive to write down his private key on a piece of paper and tape it to his monitor. A strategy nearly as bad would be for him to store the unencrypted private key in a file, particularly one with open read permissions. Encrypting a private key under a password would be better, but passwords themselves, being vulnerable to guessing, eavesdropping, sharing, as well as dictionary and exhaustive search attacks, are by no means secure. Even with encrypted storage, the key must be decrypted before it may be utilised in cryptographic functions, being particularly vulnerable during that time. In addition, a computer itself may, in many ways, be an uncontrolled environment from the user's perspective and everything from legitimate memory management to viruses and other host-based attacks may wreak havoc with the protection of the private key. It bears repeating that even strong encryption, utilised in a perfectly designed protocol, is only as secure as the protection given to its keys. If the private key is poorly protected, it may be a case of installing a triple-bolted steel front door and then leaving a key under the mat. An appropriate response to this type of protection would be to either demand stronger identification and authentication than a password alone or remove the private key from the computer and place it in a secured environment. Diffie and Hellman have devised an algorithm not requiring a centralised key distribution system. Unfortunately, the original Diffie-Hellman technique was vulnerable to an active "man-in-the-middle-attack". However, this vulnerability can be mitigated. The solution is in using signed keys to authentically bootstrap into the Diffie-Hellman exchange. CAs are essentially about trust. The retrieval of a digital certificate could result in an "unknown" and therefore "untrusted" CA name. This typically occurs between two parties who have digital certificates from two differing CAs. CAs can form a hierarchy, often referred to as the trust chain. Each member in the chain has a certificate signed by its superior authority. The higher the CA is in the chain, the tighter security procedures are in place. The root CA is trusted by everyone and its private key is real top secret. A communicating party can traverse the chain upwards until a CA is found that is trusted. The traversal consists of verifying the subordinate CA's public key and identity using the certificate issued to it by the superior CA. An implementation of this concept can be found in the SET protocol, where the major credit card brands operate their own CA hierarchies that converge to a common root. Lotus Notes authentication, as another example, is also based on certificates, and it can be implemented using hierarchical trust chains. PGP also uses a similar approach, but its trust chain is based on persons and it is rather a distributed web than a strict hierarchical tree. Within VPNs, CAs are fast becoming the primary method of authenticating identity. They provide the highest level of confidence that claimed identity is actual identity. The combination of often-stringent corporate and government information security needs with the desire to take advantage of the interconnectivity afforded by open networks, such as the Internet, creates a dilemma in which cryptographic techniques play a large role in resolving. With the development of strong cryptographic algorithms and protocols, it is only natural that key compromise should be an even more attractive target, as an attacker follows the "path of least resistance". If private key compromise is no harder than the compromising of a password, then the security offered by cryptographic techniques is reduced to the same level, if not lower due to the false sense of security placed in their use. We have also seen that even sending actual public keys over the WAN leaves the door wide open for attack. The following guidelines will ensure that who you think you are authenticating is actually who you are authenticating. Always use a standards based approach to provide a solution which is fully compliant with both IP Layer Security Protocol (IPSec) Always use a standards base key management to ensure keys are never compromised. It is recommended that the solution be compliant with The Internet Key Exchange (IKE) protocol Never send private, public or even pre-shared keys over the WAN. IKE can ensure that the actual keys are never sent over the WAN Use digital certificates and digital signatures to authenticate identity of user the actual CA

Read more on Voice networking and VoIP