PIX CA Support Overview
The PIX Firewall supports the following open CA standards:
IKEA hybrid protocol that implements Oakley and Skeme key exchanges inside the ISAKMP framework. Although IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec SAs.
Public-Key Cryptography Standard #7 (PKCS #7)A standard from RSA Security Inc. used to encrypt and sign certificate enrollment messages.
Public-Key Cryptography Standard #10 (PKCS #10)A standard syntax from RSA Security Inc. for certificate requests. The PIX Firewall automatically creates the certificate requests as part of the SCEP process.
RSA keysRSA is the public key cryptographic system developed by Ronald Rivest, Adi Shamir, and Leonard Adelman. RSA keys come in pairs: one public key and one private key.
X.509v3 certificatesCertificate support that allows the IPSec-protected network to scale by providing the equivalent of a digital ID card to each device. When two devices wish to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or to manually specify a shared key at each peer). These certificates are obtained from a CA. X.509 is part of the X.500 standard.
CA interoperabilityCA interoperability permits CAs to communicate with your PIX Firewall so that it can obtain and use digital certificates from the CA. Although IPSec can be implemented in your network without the use of a CA, using a CA with SCEP provides manageability and scalability for IPSec.
The PIX Firewall supports the SCEP to automate the exchange of certificates with a CA server.
The SCEP is an Internet Engineering Task Force (IETF) draft sponsored by Cisco that provides a standard way of managing the certificate lifecycle. This initiative is important for driving open development for certificate handling protocols that can be interoperable with many vendors' devices.
PKCS #7 and #10 are acronyms for the Public-Key Cryptography Standards #7 and #10. These are standards from RSA Security Inc. used to encrypt and sign certificate enrollment messages.
The Manual Enrollment Process
SCEP provides two authentication methods: manual authentication and authentication based on a preshared secret. In the manual mode, the end entity submitting the request is required to wait until the CA operator, using any reliable out-of-band method, can verify its identity. An MD5 fingerprint generated on the PKCS # must be compared out-of-band between the server and the end entity. SCEP clients and CAs (or RAs, if appropriate) must display this fingerprint to a user to enable this verification, if manual mode is used. When using a preshared secret scheme, the server should distribute a shared secret to the end entity that can uniquely associate the enrollment request with the given end entity. The distribution of the secret must be private: only the end entity should know this secret. When creating the enrollment request, the end entity is asked to provide a challenge password. When using the preshared secret scheme, the end entity must type in the redistributed secret as the password. In the manual authentication case, the challenge password is also required because the server might challenge an end entity with the password before any certificate can be revoked. Later on, this challenge password will be included as a PKCS #10 attribute and will be sent to the server as encrypted data. The PKCS #7 envelope protects the privacy of the challenge password with Data Encryption Standard (DES) encryption.
CA Servers Interoperable with PIX Firewall
There several other CA vendors that interoperate with PIX Firewalls, as follows:
Entrust Technologies, Inc.Entrust/PKI 4.0
Baltimore TechnologiesUniCERT v3.05
Microsoft CorporationWindows 2000 Certificate Services 5.0
Each of the CA vendors supports the SCEP for enrolling PIX Firewalls. Cisco is using the Cisco Security Associate Program to test new CA and PKI solutions with the Cisco Secure family of products. More information on the Security Associate Program can be found at the following URL:
The Entrust CA server is one of the servers interoperable with Cisco. One of the major differences among CA servers is the question of who administers it.
Entrust is software that is installed and administered by the user. The Cisco IOS interoperates with the Entrust/PKI 4.0 CA server. Entrust/PKI delivers the ability to issue digital IDs to any device or application supporting the X.509 certificate standard, meeting the need for security, flexibility, and low cost by supporting all devices and applications from one PKI. Entrust/PKI offers the following features:
RequirementsEntrust runs on the Windows NT 4.0 (required for Cisco interoperability), Solaris 2.6, HP-UX 10.20, and AIX 4.3 operating systems. Entrust requires RSA usage keys on the routers. You must use PIX Firewall release 5.1 and later.
Standards supportedEntrust supports CA services and the RA capability, SCEP, and PKCS #10.
Refer to the Entrust Web site at http://www.entrust.com for more information.
VeriSign OnSite 4.5
The VeriSign OnSite CA server is interoperable with PIX Firewalls. VeriSign administrates the CA, providing the certificates as a service.
VeriSign's OnSite 4.5 solution delivers a fully integrated enterprise PKI to control, issue, and manage IPSec certificates for PIX Firewalls and Cisco routers. VeriSign OnSite is a service administered by VeriSign. VeriSign OnSite offers the following features:
RequirementsThere are no local server requirements. Configure the router for CA mode with a high (greater than 60 second) retry count. You must use PIX Firewall release 5.1 and later.
Standards supportedIt supports SCEP, x509 certificate format, and PKCS #7, #10, #11, #12.
Refer to the VeriSign Web site at http://www.verisign.com for more information.
Baltimore Technologies has implemented support for SCEP in UniCERT (Baltimore's CA server) as well as the PKI Plus toolkit; these make it easy for customers to enable certificates within their environments.
RequirementsThe current release of the UniCERT CA module is available for Windows NT. You must use PIX Firewall release 5.2 and later.
Standards supportedThe following standards are supported with this CA server: X509 v3, X.9.62, X.9.92, X9.21-2; CRl v2; RFC 2459; PKCS #1, #7, #10, #11, #12; RFC 2510, RFC 2511; SCEP; LDAP v2, LDAP v3; DAP; SQL; TCP/IP; POP3; SMTP; HTTP; OCSP; FIPS 186-1, FIPS 180-1, FIPS 46-3, and FIPS 81 CBC.
Refer to the Baltimore Web site at http://www.baltimore.com for more information.
Microsoft Windows 2000 Certificate Services 5.0
Microsoft has integrated SCEP support into the Windows 2000 CA server through the Security Resource Kit for Windows 2000. This support lets customers use SCEP to obtain certificates and certificate revocation information from Microsoft Certificate Services for all of Cisco's VPN security solutions.
RequirementsYou need a compatible PC capable of running Windows 2000 Server. You must use PIX Firewall release 5.2 and later.
Standards supportedThe following standards are supported with this CA server: X.509 version 3, CRL version 2, PKCS family (PKCS #7, #10, #12), PKIX, SSL version 3, Kerberos v5 RFC 1510, 1964 tokens, SGC, IPSec, PKINIT, PC/SC, and IETF 2459.
See Chapter 3, "Configuring Cisco IOS Routers for Preshared Keys Site-to-Site," for more information about configuring the Microsoft Windows 2000 CA for SCEP support.
Refer to the Microsoft Web site at http://www.microsoft.com for more information.
Enroll a Device with a CA
The typical process for enrolling in a CA follows:
Configure the PIX Firewall for CA support.
The public and private keys are generated on the PIX Firewall.
The PIX Firewall authenticates the CA server.
The PIX Firewall sends a certificate request to the CA.
The CA signs the certificate.
The CA returns the certificate to the PIX Firewall and posts the certificate in the public repository (directory).
Most of these steps have been automated by Cisco and the SCEP protocol that is supported by many CA server vendors. Each vendor determines how long certificates are valid. Contact the relevant vendor to determine how long the certificates will be valid in your particular case.