Dreez's
PKI Single Sign-On Project

FW1 VPN Single Sign-On

Revision Control

Contact Dreez: mje@secev.com

Overview

External-to-internal access is a worst case scenario in the information security world. Security administrators can never really be sure who that external person is regardless of how much technology you throw at the problem (including PKI). Only physical control over computing assets give you the highest possible guarantee of secured access.

Unfortunately, the business world is not perfect and CEOs want to read their email while they are on the road. The next best thing to physical control is strongly authenticated access. There are several forms of strong authentication available to us:

1. Biometrics
2. Tokens
3. PKI

Biometrics and tokens do a pretty good job of authenticating access, but after authenticating the first couple packets, the connection is open to the world. The next best thing is PKI authentication because not only do you authenticate the first couple packets, you have the option of encrypting the resulting data stream and authenticating every packet thereafter with your private session key.

Initially PKI authentication requires more work for users and system administrators to setup because current technology does not integrate PKI real cleanly right now. Certificates must be assigned to various parts of the system, and multiple systems must all work together to make sure the authentication works correctly.

1. A Root CA must be established to sign certificates for all participants
2. A CRL distribution point associated with the CA must exist so the participants can ensure the certificate is valid.
3. A LDAP server must exist that stores all the usernames of all the VPN clients
4. The LDAP server must be configured to store information from PKI enabled applications, such as Checkpoint's VPN system.
5. Root certificates must be distribute to all participants
6. Certificates signed by Root CA must be distributed to all participants
7. The VPN server must be configured to interoperate with the CRL/LDAP server to verify information during PKI authentication.
8. The client must be configured to authenticate with PKI certificates
9. Client must be able to query CRL servers

But after the setup is complete, the users usually only interact with PKI when they unlock their certificate with a username password. The point being, after the initial setup the interaction with the PKI system is minimal and a process users understand (username password). In addition, the username password is something the user creates and maintains, not a central administrator.

What this buys you is the ability to rid your organization's centrally administered username and password database (costly and hacker prone) AND provide the capability for staff and remote clients to access internal resources securely.

The first step in this process is to prepare your infrastructure for centralized control over VPN activity. We will use Microsoft's Active Directory with its LDAP interface as the repository for all VPN information.  We will need to extend AD with VPN information in order to store and manage user accounts on Active Directory. So before you do anything with VPN,  you need to configure Active Directory to work with FW1. See how to configure Active Directory.

The next step is to PKI enable the firewall with a Root CA  and and then assign a certificate to the firewall. Then PKI create a   VPN Certificate  and installing the certificate on the client.The final step is to VPN Enable  the user  in the Active Directory database. 

Each of these steps are described in detail in the associated sections.

Design Eval

1. Limit complexity - One certificate to log into the world with, eliminate all the PKI fluff that is bogging down PKI.  

2. Functionality wins - Functionality and ease-of-use over security at all times. Just the fact that I am ridding the world of a centralized user/password database means I am winning. Forget all the other security fluff that raises the ire of users causing them to end-run security.

3. Centralized control - Centralized database within Active Directory/LDAP

4. Distributed administration - Distributed management of centralized database (e.g. VPN GUI can manage VPN users, but centralized database keeps all user info)

5. Avoiding doing CEO stuff - I'm a CEO, but with a geek habit that I have to feed

Design Goal Evaluation

This is my personal evaluation if I met my design goals. OK, I admit I'm biased....

Debugging

We built a FAQ that listed all the problems we ran into during PKI/VPN integration. Refer to this FAQ for assistance. VPN FAQ.

Home | Services | Training | Support | Contact Us | Search

Copyright 2006, Security Evolution, Inc.