Stronger Authentication: How to Use Certificates with MUVPN
by David M. Piscitello, President, Core Competence, Inc.
I've written many editorials explaining how IPSec-based Virtual Private Networks can be used to secure site-to-site as well as remote access communications throughout your organization. In my editorial, "Understanding Certificates and PKI," I said, “If I could apply one security remedy ubiquitously, it would be this: eliminate passwords by introducing some combination of stronger authentication methods.” With WatchGuard Firebox System (WFS) version 6.0, I can now use strong authentication with all the WatchGuard gear I manage. This editorial describes how you can use digital certificates to strengthen the security of your Mobile User VPN.
Integrated Public Key Infrastructure
Let's begin with a brief reminder from my earlier PKI editorial. A digital certificate contains the name and the public key of the entity communicating with you. The certificate binds the public key to the named person or a system. With MUVPN, certificates bind unique public keys to each mobile user and to the Firebox to which mobile users will tunnel.
WFS 6.0 comes with a built-in Certificate Authority (CA) server. This server allows you, the firewall administrator, to act as the acknowledged and trusted third party issuer and guarantor of certificates for your organization. When you have your CA digitally sign mobile user certificates, you are guaranteeing that each certificate contains accurate, complete, and unaltered information about the named person or system, including that entity's public key.
You must enable the CA before you attempt to use certificate-based authentication. The built-in CA activates automatically when you enable the Firebox's DVCP server through the VPN Manager or directly from the Firebox Policy Manager. The parameters you need to set are:
-
The registered Domain Name of your organization (for example, corecom.com)
-
A CRL (Certificate Revocation List) Distribution Point, the IP address accessed by MUVPN users or other WatchGuard firewalls to verify that certificates presented during VPN tunnel establishment have not been revoked
-
A CRL Publication Period to control how frequently a revised CRL is published
-
A Client Certification Validation Period to control how long a client certificate will remain valid (from the creation date)
-
A Root Certificate Validation Period to control how long the CA's own certificate will remain valid (from the creation date)
-
Log, log, log! Turn on all the debug and logging facilities. It's the best way to learn how the built-in CA works and interacts with IPSec.
Verify that you set a Domain Name when you performed your initial network configuration (Network => Configuration… => WINS/DNS). If this field is blank, your CA will generate certificates that are bound to the Firebox's external IP address (e.g., GW:10.0.0.1) rather than an associated domain name (e.g., fb3.corecom.com). Such certificates are perfectly valid and usable, but will be invalidated if you ever re-number the external interface of your Firebox. A fully-qualified domain name insulates your certificates from any future IP updates by using DNS to map your Firebox's name to its current public IP address.
Once you've enabled the CA/DVCP server, you can manage certificates using a Web browser. I find that a more convenient and nearly transparent method of issuing certificates is to use the Mobile User VPN Wizard (explained next).
Remote User Setup: The Administrator's Roles
Whether you are creating new MUVPN users or upgrading authentication for existing MUVPN users, you'll have two small tasks to complete using the MUVPN Wizard. First, choose “Use a certificate (RSA signature) that will be issued by this Firebox's CA/DVCP server” from the expanded configuration window when you configure the IPSec Tunnel Authentication Method. (In the terminology of the IETF's RFC, this is called the IKE authentication method.) Second, when you opt to use certificates, you'll be prompted to complete Certificate Authority Configuration. Here, supply the IP address of the CA (Firebox) that will automatically issue a user certificate and the CA administrator's passphrase (i.e., the passphrase entered when you enabled the CA/DVCP server).
These two tasks are the essence of certificate creation with the Firebox's built-in CA. When you enter the CA passphrase, you are identifying and offering proof (credentials) that you are the CA admin, and you are authorizing the CA/DVCP server to issue a certificate to the user whose configuration profile you are creating. This certificate will be valid for the Client Certification Validation Period you specified when you enabled the CA/DVCP server. When this period expires, this user's certificate becomes invalid, and the CA/DVCP server publishes this change of certificate status in the Certificate Revocation List.
The rest of the MUVPN Wizard configuration process remains the same as before: specify a Virtual IP address for this user, identify the networks and services the user will be able to access, and select tunnel security parameters. When the wizard completes, you'll have created a folder in a user subdirectory (e.g., D:\Program Files\WatchGuard\Ruvpn\fb1000.hhi.corecom.com\wgx\ davep) that contains the following files:
-
An encrypted MUVPN configuration file (.wgx) containing the client security policy for this user
-
An encrypted, passphrase-protected PKCS #12 file (.p12) containing the user's personal certificate (the user's identity, public key, and the identity of the issuing CA) and the user's private key
-
A standard base 64-encoded public certificate file (.pem) containing the Firebox CA's root certificate (the CA's identity, public key, and CRL distribution point)
These three files must be distributed to the user, along with MUVPN 6.0 client software (e.g., MUVPN.exe or MUVPNlite.exe) and the secret passphrase the user must know to install the software, security policy, and associated personal certificate.
MUVPN Setup: The User's Role
When you bundle and distribute the client software, certificates, and configuration file to your users, you can minimize support calls if you supply instructions on how to properly complete MUVPN installation. I recommend you mention at least the following:
- Your users should remove prior versions of the MUVPN client before installing the Version 6.0 client software. I always find it better to begin with as clean an install environment as possible.
-
Wait until prompted during installation, or the first time the MUVPN client runs, to supply the security policy (the .wgx configuration file). When MUVPN processes the .wgx file, it automatically installs the client's security policy database, your Firebox's root CA certificate, the MUVPN user's personal certificate, and the associated private key that MUVPN will use to prove this user is authentic.
-
Users may be tempted to manually install certificates via the MUVPN Certificate Manager. Recommend that they verify that certificates have been installed using the Certificate Manager first, and avoid re-installing the user's personal certificate unnecessarily. Reinstalling certificates after installing the .wgx file may break the binding between the security policy and the user's certificate, requiring the security policy to be edited to re-establish that binding.
-
Instruct your users on how to verify that the installation and configuration import has gone smoothly. (This can save you hours of trouble-shooting frustration.) To check their settings, have them open the MUVPN Security Policy Editor, select the automatically-configured VPN policy, and verify that the user's certificate is selected under My Identity. This should be true unless the user's certificate has been reinstalled or updated after the original .wgx installation. In that unusual case, the user can easily re-establish the binding between certificate and policy by selecting the user's certificate from the pulldown menu. After doing so, verify that My Identity is ID Type Distinguished Name and that the Phase 1 Authentication method is RSA Signatures (digital certificates). Have the user Save and then Reload the modified policy to put the changes into effect.
-
Familiarize the user with the Connection Monitor, Log Viewer, and how to activate the Security Policy from the System Tray.
At this point, your user should be ready to rock and roll with stronger authentication!
Establishing a User VPN Tunnel
If you've enabled logging, you should look for the following log events (abbreviated), which indicate a successful MUVPN connection with certificate-based authentication:
iked[9916]:FROM 10.0.0.2 MM-HDR ISA_SA ISA_VENDORID
iked[9916]:TO 10.0.0.2 MM-HDR ISA_SA
iked[9916]:FROM 10.0.0.2 MM-HDR ISA_KE ISA_NONCE ISA_VENDORID ISA_VENDORID ISA_VENDORID
iked[9916]:Received KEEPALIVE vendor ID
iked[9916]:TO 10.0.0.2 MM-HDR ISA_KE ISA_NONCE ISA_CERT_REQ
iked[9916]:CRYPTO ACTIVE after delay
iked[9916]:FROM 10.0.0.2 MM-HDR* ISA_ID ISA_CERT ISA_CERT_REQ ISA_CERT_REQ ISA_SIG ISA_NOTIFY
At this point, Phase 1 (IKE SA negotiation) is in progress, and the Firebox is attempting to validate the client certificate:
validator[100]:Got certificate data
validator[100]:Got Peer Subject name:/O=corecom.com/OU=GW:10.0.0.1/CN=davep
validator[100]:verified using CA cert #0.
validator[100]: Using cached CRL for http://10.0.0.1:4113/wgca.crl
validator[100]: sent back TID = 12 iked[9916]: Tid = 12, Validation server returned: Cert validation success
Now that the client's certificate has been validated, IKE SA processing (Phase 1) and virtual IP address assignment continues:
iked[9916]: Certificate from 10.0.0.2 is valid:
iked[9916]: Attempting to update laddr 10.0.0.2 to ruser_ip 10.0.0.1
iked[9916]: Updated davep001 channel for davep rgw
iked[9916]: User "davep" at 172.16.0.202 logged in
iked[9916]: Add Host 14 172.16.0.202 ipsec_users davep succeeded
iked[9916]: davep, from 10.0.0.2 bound to 172.16.0.202
iked[9916]: Setting attributes (DNS and WINS)
iked[9916]: TO 10.0.0.2 TR-HDR*-50FAEDCC ISA_HASH ISA_TRANSATTR
iked[9916]: Ending phase1 as RESPONDER
iked[9916]: FROM 10.0.0.2 TR-HDR*-50FAEDCC ISA_HASH ISA_TRANSATTR
iked[9916]: Processing configuration acknowledge
iked[9916]: Remote set INTERNAL_IP4_ADDRESS
iked[9916]: Remote set INTERNAL_IP4_NETMASK
Next, IPSec Security Association processing begins:
iked[9916]: FROM 10.0.0.2 QM-HDR*-02C7B324 ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID
iked[9916]: Getting IPSEC preferences as Responder propnum=1, mode=(Tunnel), laddr=10.0.0.1, raddr=10.0.0.2
iked[9916]: TO 10.0.0.2 QM-HDR*-02C7B324 ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID
iked[9916]: FROM 10.0.0.2 QM-HDR*-02C7B324 ISA_HASH
iked[9916]: Load outbound ESP SA, Algs=ESP_3DES/AUTH_ALG_HMAC_SHA1 Life=86400sec/0KB SPI=6BF2AC8E
iked[9916]: Load inbound ESP SA, Algs=ESP_3DES/AUTH_ALG_HMAC_SHA1 Life=86400sec/0KB SPI=18047F0C
iked[9916]: Tunnel created for 172.16.0.0/24 <-> 172.16.0.202/32
iked[9916]: Committing SAs for channel=4 established with QM message_id=02C7B324
And the client proceeds to open an ftp session over the encrypted and strongly authenticated tunnel:
firewalld[102]: allow in ipsec0 48 tcp 20 128 172.16.0.202 172.16.0.2 1283 21 syn (FTP)
Conclusions
In the VPN Day workshops I teach with Lisa Phifer, Joel Snyder, and Fred Avolio, we conclude our demonstrations with a discussion of the pros and cons of using built-in CAs. From my initial experimentation with the CA/DVCP server, I observe that:
- The built-in CA represents stronger authentication than pre-shared secrets, at zero incremental cost over the cost of the Firebox itself to an organization, but credentialing is more limited than a commercial, off-the-shelf CA or public certificate provider. This should not be a problem for organizations deploying certificates for VPN purposes only.
-
The CA/DVCP's Certificate repository resides in your Firebox. If the Firebox running as your CA/DVCP server goes offline, you lose your CA as well. Large VPN deployments should consider a high-availability configuration for their CA/DVCP servers.
-
The certificates and CRLs the CA/DVCP server issues are accessible to other WatchGuard security appliances and MUVPN clients. The built-in CA creates the CA root and client certificates in exportable formats. However, you can't import certificates generated by another-vendor CA product, and other-vendor Security Gateways may not be able to use the certificates that you issue with your built-in CA. In our experience with numerous VPN products, these caveats are typical of built-in CAs.
Overall, certificate-based authentication is a welcomed improvement over the typically weak passphrases employed today. I will be applying this security remedy ubiquitously. ##
Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.