By Garret Grajek
COO, MultiFactor Corp.
Common practice for “secured” IPsec VPNs is to :
(a) Issue One-Time-Password “tokens” to users
(b) Encrypt the channel with a “Shared” encryption key
This article will address the problem with (b), creating the encryption key with a “Shared Secret”.
As stated, standard practice is to go through the painful, laborious and unappreciated (by users) task of distributing and maintaining one-time-password tokens to end users. This process, by itself is not trivial – and is fraught with its own set of security issues. (Tokens, by themselves, do not increase the security factor of insuring the end-user is communicating with the appropriate server. They only add a security factor in ensuring the identity of the user. E.g. client side authentication versus mutual, bi-lateral authentication.)
What is not stated by the token-selling community (be it “hard” token or “soft” token”) is that the actual encryption channel is still a “manually” distributed “shared key”. The shared key is often distributed via an easily attackable channel such e-mail, FTP sites and/or a shared document repository. It is this manual process that makes the IPsec channel most vulnerable – that is not the fact that it’s a shared secret – but how the shared secret is distributed.
Once this shared secret is distributed – in most cases - the user manually inputs this “shared key” in the designated spot. (See Diagram #1)Diagram #1 – Shared Key Need for non-Certificate based IPsec encryption
OK, enough FUD. How does one set up a secure VPN channel, where the encryption channel is NOT trivially hacked?
The “best practice” solution is to utilize X.509 public/private key technology. This means distributing a PKI certificate to an end user and setting up the encryption using that certificate.
Now I just lost 90% of the readers, right there, by stating these (2) items need to be done:
1) Distribute a X.509 Public/Private Key
2) Have the end-user create a IPsec profile using the distributed key pair.
But wait – what if there was a system that can automate these (2) practices?
There is. It’s called “MultiFactor SecureAuth® for VPNs”.
MultiFactor SecureAuth® for VPNs has the ability to securely enroll the end-user and distribute the public/private key in a trivial user registration process. The end user receives the certificate after he/she has been securely registered using one of the many SecureAuth® registration methods. (SMS Text Messaging, Telephony One-Time Passwords, E-mail or Static PIN – see diagram #2)
Diagram #2 - Registration with MultiFactor SecureAuth®
Once the user successfully registers, the SecureAuth® client handles the insertion of the public/private key to where the VPN IPsec client can find the key pair. This key pair is stored, in the browsers natives key store (IE uses Microsoft key store, FireFox utilizes NSS keystore, and Apple Safari utilizes Apple KeyChain.)
But to truly make the process secure – we have to contend with informing the IPsec client how to create the encryption channel – with the X.509 key pair that was just created. Once again, MultiFactorSecureAuth® automatically handles this process – by creating a user profile that uses the key to create the encrypted channel.
Let me repeat, the MultiFactor SecureAuth® product, when the user successfully conducts a user-self-registration creates a Private-Public key pair AND an IPsec profile that automatically uses this key par. (Diagrams #3 and #4).
Thus, MultiFactor SecureAuth® both the two-sided coin of VPN authentication : authentication and encryption.
Diagram # 3 – SecureAuth® automatically creates a user profile
Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.