Republished with permission from
WatchGuard Technologies, Inc.
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:
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:
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:
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:FROM 10.0.0.2 MM-HDR ISA_SA ISA_VENDORID
iked:TO 10.0.0.2 MM-HDR ISA_SA
iked:FROM 10.0.0.2 MM-HDR ISA_KE ISA_NONCE ISA_VENDORID ISA_VENDORID ISA_VENDORID
iked:Received KEEPALIVE vendor ID
iked:TO 10.0.0.2 MM-HDR ISA_KE ISA_NONCE ISA_CERT_REQ
iked:CRYPTO ACTIVE after delay
iked: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:Got certificate data
validator:Got Peer Subject name:/O=corecom.com/OU=GW:10.0.0.1/CN=davep
validator:verified using CA cert #0.
validator: Using cached CRL for http://10.0.0.1:4113/wgca.crl
validator: sent back TID = 12 iked: 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: Certificate from 10.0.0.2 is valid:
iked: Attempting to update laddr 10.0.0.2 to ruser_ip 10.0.0.1
iked: Updated davep001 channel for davep rgw
iked: User "davep" at 172.16.0.202 logged in
iked: Add Host 14 172.16.0.202 ipsec_users davep succeeded
iked: davep, from 10.0.0.2 bound to 172.16.0.202
iked: Setting attributes (DNS and WINS)
iked: TO 10.0.0.2 TR-HDR*-50FAEDCC ISA_HASH ISA_TRANSATTR
iked: Ending phase1 as RESPONDER
iked: FROM 10.0.0.2 TR-HDR*-50FAEDCC ISA_HASH ISA_TRANSATTR
iked: Processing configuration acknowledge
iked: Remote set INTERNAL_IP4_ADDRESS
iked: Remote set INTERNAL_IP4_NETMASK
Next, IPSec Security Association processing begins:
iked: FROM 10.0.0.2 QM-HDR*-02C7B324 ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID
iked: Getting IPSEC preferences as Responder propnum=1, mode=(Tunnel), laddr=10.0.0.1, raddr=10.0.0.2
iked: TO 10.0.0.2 QM-HDR*-02C7B324 ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID
iked: FROM 10.0.0.2 QM-HDR*-02C7B324 ISA_HASH
iked: Load outbound ESP SA, Algs=ESP_3DES/AUTH_ALG_HMAC_SHA1 Life=86400sec/0KB SPI=6BF2AC8E
iked: Load inbound ESP SA, Algs=ESP_3DES/AUTH_ALG_HMAC_SHA1 Life=86400sec/0KB SPI=18047F0C
iked: Tunnel created for 172.16.0.0/24 <-> 172.16.0.202/32
iked: 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: allow in ipsec0 48 tcp 20 128 172.16.0.202 172.16.0.2 1283 21 syn (FTP)
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:
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.
Copyright © 1996 - 2002
WatchGuard Technologies, Inc. All rights reserved.