Overview of Cisco Router CA Support

When two peer routers initiate an exchange of IPsec-protected traffic, they must first authenticate each other. The authentication is performed with Internet Key Exchange (IKE) and the preselected key-exchange method. The advantage of using CA support is that peers no longer need to manually exchange preshared keys or nonces. When two peers begin the IKE negotiation, they just exchange public keys, which are then authenticated by the CA. This process greatly improves manageability because there is no requirement to track keys. As a result, this solution is easy to scale. Cisco IOS Software supports the following CA standards:

• IPsec IPsec is a framework of open standards that provide authentication, integrity, and confidentiality of data between peers.

• RSA keys Rivest, Shamir, and Adelman (RSA) is an asymmetric public key cryptography system. RSA keys come in key pairs (one public and one private). When generating RSA keys, it is also possible to generate an authentication pair and an encryption pair.

• IKE IKE is a combination of ISAKMP and the Oakley key exchange protocols. Also referred to as ISAKMP/Oakley , it provides a method of authentication and negotiation to create a secure environment for the IPsec negotiation.

• CA interoperability CA interoperability is the component that provides communication functionality between Cisco devices and CA servers. A main component of CA interoperability is the Simple Certificate Enrollment Protocol (SCEP):

- SCEP is a lightweight transaction-oriented protocol that uses Public Key Cryptography

Standard #7 (PKCS#7) and PKCS#10. SCEP requires either manual authentication or a preshared key during enrollment.

• X.509v3 certificates X.509 is a digital certificate standard that was created using the X.500 standard as its foundation. It allows peers to exchange digital certificates to authenticate their identity. This solution removes the requirement for manually exchanging public keys between peers. The following CA services use X.509v3 certificates and also support SCEP:

- VeriSign OnSite 4.5

- Entrust Technologies

- Baltimore Technologies

- Windows 2000 Certificate Server 5.0

• PKCS#7 A standard from RSA used to encrypt, sign, and package certificate enrollment messages.

• PKCS#10 A standard from RSA that defines the syntax for certificate requests.

Several things take place when sending traffic from the source to the destination via a VPN connection. Figure 20-3 shows how traffic gets from the source system on the New York network to the destination system on the Boston network and how the peers communicate with each other and the CA server for peer authentication. Source A generates traffic destined for destination B, and the traffic is passed to the router. The router (New York) compares the traffic to its current security policy and determines that the traffic must be encrypted and forwarded to the VPN endpoint router (Boston). The New York network checks for an existing IPsec security association (SA) with the

Boston router, and if no IPsec SA exists, the router initiates the negotiation of an IKE SA. As part of the IKE SA negotiation, both routers exchange digital certificates that have been signed by a CA that is trusted by both peers. Upon receiving the certificate from the peer, each router downloads a certificate revocation list (CRL) from either the CA or a CRL distribution point and verifies that the certificate from the peer has not been revoked. After verifying the certificates, the peers complete the negotiation of the IKE SA, followed by the negotiation of the IPsec SA. The data is transferred between the source and destination as soon as the VPN tunnel is created.

As Figure 20-3 illustrates, the CA server is accessible to both peers. The peers exchange digital certificates, and the CA server validates the certificate. The CA maintains a list of certificates that are no longer valid called a CRL. The peers ensure that a certificate is valid by checking it against the CRL.

0 0

Post a comment