Achieving two-factor authentication with digital certificates. Are costly OTP token solutions dead?

It is widely accepted that one of the best things you can do to secure your sslvpn infrastructure is implementing a two-factor authentication scheme. Typically, this has been accomplished using a one-time password token technology. But what about using digital certificates that are tied to usernames instead of an OTP token approach? The idea being that the certificate is the something you have and the username/pwd is the something you know. This is a newly supported feature on the Cisco ASA, but not new to the industry, so I thought it might be interesting to examine it.

The common reasons given for choosing a certificate approach are cost savings, ease of use, standards based, and lower total cost of ownership. I’m not completely sold on the idea yet but think it is worth discussing and analyzing. This approach is relatively new but gaining in popularity.

So here is the user experience and behind the scenes flow of the solution:

• User gets authorized to use the sslvpn service at their company. The sslvpn administrator creates the new user account on the authentication server and in the certificate database. Admin makes sure the subject field in the user cert includes a username attribute whose value is equal to the account he created in the authentication server.
• User receives an email to enroll with the PKI and install their unique digital certificate. User completes the steps, a unique cert is now on their PC.
• User browses to the url of the sslvpn device. Behind the scenes the sslvpn device will query the user’s PC for their unique digital certificate. It will check it’s validity and extract the value of the username attribute it is looking for.
• If the cert if valid the sslvpn headend will prompt the user for authentication. However, the username field will be pre-filled in using the value from the certificate. The end user then enters their password and login completes.

Let’s dig into the details of how this certificate approach works. As is typical, to use validated digital certificates you must have a Public Key Infrastructure (PKI) that is available to your SSLVPN users. As with any PKI, you can either build your own PKI or outsource it to someone like VeriSign. As a rule of thumb, it is easiest to outsource it to a trusted Certificate Authority (CA). This eliminates the need to install trusted root certificates in every sslvpn user’s browser. The well known trusted root CA companies are already in there. The downside of outsourcing PKI is cost, it can get expensive. But even this expense should be considerably cheaper than implementing a hardware token solution for two factor authentication.

Ok, so you have your PKI in place. Now you need to issue certificates to all sslvpn users. This process varies, but can be as simple as sending users an email that contains their username, a one-time password, and a digital certificate enrollment url. The user must then go through the certificate enrollment process which will install a unique, per user, digital certificate onto their PC. Other methods of installing a certificate on each user’s PC exist so do your homework.

Now, you need to establish a typical username/password authentication mechanism for the sslvpn headend device to use to authenticate users. Popular choices are RADIUS and Active Directory LDAP.

Tying the user’s digital certificate together with their username/password is the next step to creating our two-factor authentication solution. The two must be paired together for this to work properly. This is accomplished by using the value of an attribute, found in the certificate, as the enforced username of the sslvpn user. Typically, it is a value in the subject field of the digital cert. For example, OU=jamey. The cert field chosen is determined by the headend sslvpn device administrator and can vary from tunnel group to tunnel group. The headend sslvpn device will query the certificate for this value. It will also take the value and pre-fill the username field of the typical authentication window the user sees at the client side. The user must then input the correct password for that username into the login box.

Trying to hack, change, or modify the pre-filled username field on the client side is largely irrelevant because the ASA sslvpn device effectively ignores it anyway. It only trusted the value that it received directly from its query of the certificate itself. So the hacker would have to be able to modify the certificate while maintaining its validity. A non-trivial task to say the least.

So there you have it, a two factor solution using digital certificates and username/passwords. The Cisco ASA devices support this feature starting in 8.0.3.1 code. I think this approach is very interesting but I am still biased towards the traditional OTP token solutions. Would you consider this solution truly two-factor? What pros and cons do you see? Could this approach kill the costly OTP hardware tokens, I think not, but what say you?