Cisco IOS XR, IOS XR 3.5 Configuration Manual

Cisco IOS XR System Security Configuration Guide

Cisco IOS XR Software Release 3.5

Americas Headquarters

Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000

800 553-NETS (6387)

Fax: 408 527-0883

Text Part Number: OL-12287-01

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL

C C C F L I

A b

STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of isco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo,

isco IOS, Cisco ollow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, ightStream, Linksys, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to

ncrease Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

ll other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship etween Cisco and any other company. (0710R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

Cisco IOS XR System Security Configuration Guide

Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step,

CONTENTS

Preface xi

Changes to This Document xi

Obtaining Documentation, Obtaining Support, and Security Guidelines xi

Implementing Certification Authority Interoperability on Cisco IOS XR Software SC-1

Contents SC-1

Prerequisites for Implementing Certification Authority SC-2

Restrictions for Implementing Certification Authority SC-2

Information About Implementing Certification Authority SC-2

Supported Standards for Certification Authority Interoperability SC-2 Certification Authorities SC-3

How to Implement CA Interoperability SC-5

Configuring a Router Hostname and IP Domain Name SC-6

Generating an RSA Key Pair SC-7 Declaring a Certification Authority and Configuring a Trusted Point SC-8 Authenticating the CA SC-10

Requesting Your Own Certificates SC-11 Configuring Certificate Enrollment Using Cut-and-Paste SC-12

Configuration Examples for Implementing Certification Authority Interoperability SC-14

Configuring Certification Authority Interoperability: Example SC-14

Where to Go Next SC-16

Additional References SC-16

Related Documents SC-16 Standards SC-16 MIBs SC-17

RFCs SC-17 Technical Assistance SC-17

Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software SC-19

Contents SC-20

Prerequisites SC-20

Information About Implementing IKE Security Protocol Configurations for IPSec Networks SC-20

Supported Standards SC-21 Concessions for Not Enabling IKE SC-22

IKE Policies SC-22

Cisco IOS XR System Security Configuration Guide

iii

Contents

ISAKMP Identity SC-26 ISAKMP Profile Overview SC-26

Mask Preshared Keys SC-27 Preshared Keys Using a AAA Server SC-27 Internet Key Exchange Mode Configuration SC-28

Banner, Auto-Update, and Browser-Proxy SC-29 Pushing a Configuration URL Through a Mode-Configuration Exchange SC-29 Internet Key Exchange Extended Authentication SC-30

Call Admission Control SC-30 Information About IP Security VPN Monitoring SC-31

Information About IKE for the Cisco IPSec VPN SPA on Cisco IOS XR Software SC-32

IPSec Dead Peer Detection Periodic Message Option SC-32

How to Implement IKE Security Protocol Configurations for IPSec Networks SC-32

Enabling or Disabling IKE SC-33 Configuring IKE Policies SC-34 Defining Group Policy Information for Mode Configuration SC-36

Configuring a Banner SC-40 Configuring Auto-Upgrade SC-40 Configuring a Browser Proxy SC-41

Configuring a Browser-Proxy Map to a Group SC-42 Configuring the Pushing of a Configuration URL Through a Mode-Configuration Exchange SC-43 Manually Configuring RSA Keys SC-44

Configuring ISAKMP Preshared Keys in ISAKMP Keyrings SC-48 Configuring Call Admission Control SC-50 Configuring Crypto Keyrings SC-54

Configuring IP Security VPN Monitoring SC-57

How to Implement IKE for Locally Sourced and Destined Traffic SC-58

Configuring the ISAKMP Profile for Locally Sourced and Destined Traffic SC-58

How to Implement IKE for Cisco IPSec VPN SPAs on Cisco IOS XR Software SC-62

Configuring a Periodic Dead Peer Detection Message SC-63

Configuring the ISAKMP Profile for Service Interfaces SC-64

Configuration Examples for Implementing IKE Security Protocol SC-68

Creating IKE Policies: Example SC-69

Configuring a service-ipsec Interface with a Dynamic Profile: Example SC-69 Configuring Easy VPN with a Local AAA: Example SC-70 Configuring VRF-Aware: Example SC-71

Additional References SC-73

Related Documents SC-147

Standards SC-147 MIBs SC-147 RFCs SC-148

Technical Assistance SC-148

Implementing Secure Shell on Cisco IOS XR Software SC-149

Contents SC-149

Prerequisites to Implementing Secure Shell SC-150

Restrictions for Implementing Secure Shell SC-150

Information About Implementing Secure Shell SC-151

SSH Server SC-151

SSH Client SC-151 SFTP Feature Overview SC-151 AAA Feature SC-152

Contents

How to Implement Secure Shell SC-152

Configuring SSH SC-152 Configuring the SSH Client SC-154

Configuration Examples for Implementing Secure Shell SC-156

Configuring Secure Shell: Example SC-156

Additional References SC-156

Related Documents SC-156 Standards SC-157 MIBs SC-157

RFCs SC-157 Technical Assistance SC-158

Implementing Secure Socket Layer on Cisco IOS XR Software SC-159

Contents SC-160

Prerequisites for Implementing Secure Socket Layer SC-160

Information About Implementing Secure Socket Layer SC-160

Purpose of Certification Authorities SC-160

How to Implement Secure Socket Layer SC-161

Configuring Secure Socket Layer SC-161

Configuration Examples for Implementing Secure Socket Layer SC-164

Configuring Secure Socket Layer: Example SC-164

Additional References SC-164

Cisco IOS XR System Security Configuration Guide

vii

Contents

Related Documents SC-164 Standards SC-165

MIBs SC-165 RFCs SC-165 Technical Assistance SC-165

Configuring AAA Services on Cisco IOS XR Software SC-167

Contents SC-168

Prerequisites for Configuring AAA Services SC-169

Restrictions for Configuring AAA Services SC-169

Information About Configuring AAA Services SC-169

User, User Groups, and Task Groups SC-170 Cisco IOS XR Software Administrative Model SC-172

Password Types SC-177 Task-Based Authorization SC-178 Task IDs for TACACS+ and RADIUS Authenticated Users SC-179

XML Schema for AAA Services SC-181 About RADIUS SC-182

How to Configure AAA Services SC-183

Configuring Task Groups SC-184

Configuring User Groups SC-186 Configuring Users SC-188 Configuring Router to RADIUS Server Communication SC-190

Configuring RADIUS Dead-Server Detection SC-194 Configuring Per VRF AAA SC-196 Configuring a TACACS+ Server SC-198

Configuring RADIUS Server Groups SC-201 Configuring TACACS+ Server Groups SC-203 Configuring AAA Method Lists SC-204

Applying Method Lists for Applications SC-216 Configuring Login Parameters SC-220

Configuration Examples for Configuring AAA Services SC-221

Configuring AAA Services: Example SC-221

Additional References SC-223

Related Documents SC-223 Standards SC-223

MIBs SC-223 RFCs SC-224 Technical Assistance SC-224

Cisco IOS XR System Security Configuration Guide

viii

Configuring Software Authentication Manager on Cisco IOS XR Software SC-225

Implementing Management Plane Protection on Cisco IOS XR Software SC-227

Contents SC-227

Restrictions for Implementing Management Plane Protection SC-228

Information About Implementing Management Plane Protection SC-228

Inband Management Interface SC-228 Control Plane Protection Overview SC-228 Management Plane SC-228

Management Plane Protection Feature SC-229 Benefits of the Management Plane Protection Feature SC-229

How to Configure a Device for Management Plane Protection SC-229

Configuring a Device for Management Plane Protection SC-230

Configuration Examples for Implementing Management Plane Protection SC-232

Configuring Management Plane Protection: Example SC-232

Contents

Additional References SC-233

Related Documents SC-233 Standards SC-233

MIBs SC-233 RFCs SC-234 Technical Assistance SC-234

Index

Cisco IOS XR System Security Configuration Guide

Contents

Cisco IOS XR System Security Configuration Guide

Preface

This guide describes the configuration and examples for system security.

For system security command descriptions, usage guidelines, task IDs, and examples, refer to the Cisco IOS XR System Security Command Reference.

The preface contains the following sections:

• Changes to This Document, page xi

• Obtaining Documentation, Obtaining Support, and Security Guidelines, page xi

Changes to This Document

Table 1 lists the technical changes made to this document since it was first printed.

Table 1 Changes to This Document

Revision Date Change Summary

OL-12287-01 June 2007 Initial release of this document.

Obtaining Documentation, Obtaining Support, and Security Guidelines

For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Cisco IOS XR System Security Configuration Guide

Obtaining Documentation, Obtaining Support, and Security Guidelines

Preface

Cisco IOS XR System Security Configuration Guide

xii

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Certification authority (CA) interoperability is provided in support of the IP Security (IPSec), Secure Socket Layer (SSL), and Secure Shell (SSH) protocols. CA interoperability permits Cisco IOS XR devices and CAs to communicate so that your Cisco IOS XR device 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 provides manageability and scalability for IPSec.

This module describes the tasks that you need to implement CA interoperability on your Cisco IOS XR network.

Note For a complete description of the public key infrastructure (PKI) commands used in this chapter, refer

to the Public Key Infrastructure Commands on Cisco IOS XR Software module of the Cisco IOS XR System Security Command Reference. To locate documentation for other commands that appear in this

chapter, use the command reference master index, or search online.

Feature History for Implementing Certification Authority Interoperability on Cisco IOS XR Software

Release Modification

Release 2.0 This feature was introduced on the Cisco CRS-1.

Release 3.0 No modification.

Release 3.2 Support was added for the Cisco XR 12000 Series Router.

Release 3.3.0 No modification.

Release 3.4.0 A procedure was added on how to declare the trustpoint certification

authority (CA) for both the Cisco CRS-1 and Cisco XR 12000 Series Router.

Release 3.5.0 No modification.

Contents

• Prerequisites for Implementing Certification Authority, page SC-2

• Restrictions for Implementing Certification Authority, page SC-2

• Information About Implementing Certification Authority, page SC-2

• How to Implement CA Interoperability, page SC-5

Cisco IOS XR System Security Configuration Guide

SC-1

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Prerequisites for Implementing Certification Authority

• Configuration Examples for Implementing Certification Authority Interoperability, page SC-14

• Additional References, page SC-16

Prerequisites for Implementing Certification Authority

The following prerequisites are required to implement CA interoperability:

• You must be in a user group associated with a task group that includes the proper task IDs for

security commands. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.

• You must install and activate the Package Installation Envelope (PIE) for the security software.

For detailed information about optional PIE installation, refer to the Cisco IOS XR System Management Guide.

• You need to have a CA available to your network before you configure this interoperability feature.

The CA must support Cisco Systems PKI protocol, the Simple Certificate Enrollment Protocol (SCEP) (formerly called certificate enrollment protocol [CEP]).

Restrictions for Implementing Certification Authority

Cisco IOS XR software does not support CA server public keys greater than 2048 bits.

Information About Implementing Certification Authority

To implement CA, you need to understand the following concepts:

• Supported Standards for Certification Authority Interoperability, page SC-2

• Certification Authorities, page SC-3

Supported Standards for Certification Authority Interoperability

Cisco supports the following standards:

• IPSec—IP Security Protocol. IPSec is a framework of open standards that provides data

confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses Internet Key Exchange (IKE) to handle negotiation of protocols and algorithms based on local policy, and to generate the encryption and authentication keys to be used by IPSec. IPSec can be used to protect one or more data flows between a pair of hosts, a pair of security gateways, or a security gateway and a host.

• IKE—A hybrid protocol that implements Oakley and Skeme key exchanges inside the Internet

Security Association Key Management Protocol (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 security associations (SAs).

• Public-Key Cryptography Standard #7 (PKCS #7)—A standard from RSA Data Security Inc. used

to encrypt and sign certificate enrollment messages.

Cisco IOS XR System Security Configuration Guide

SC-2

Implementing Certification Authority Interoperability on Cisco IOS XR Software

• Public-Key Cryptography Standard #10 (PKCS #10)—A standard syntax from RSA Data Security

Inc. for certificate requests.

• RSA keys—RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and

Leonard Adelman. RSA keys come in pairs: one public key and one private key.

• SSL—Secure Socket Layer protocol.

• X.509v3 certificates—Certificate support that allows the IPSec-protected network to scale by

providing the equivalent of a digital ID card to each device. When two devices want to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or specify a shared key at each peer). These certificates are obtained from a CA. X.509 is part of the X.500 standard of the ITU.

Certification Authorities

The following sections provide background information about CAs:

• Purpose of CAs, page SC-3

• IPSec Without CAs, page SC-4

Information About Implementing Certification Authority

Purpose of CAs

• IPSec with CAs, page SC-4

• IPSec with Multiple Trustpoint CAs, page SC-4

• How CA Certificates Are Used by IPSec Devices, page SC-5

• CA Registration Authorities, page SC-5

CAs are responsible for managing certificate requests and issuing certificates to participating IPSec network devices. These services provide centralized key management for the participating devices.

CAs simplify the administration of IPSec network devices. You can use a CA with a network containing multiple IPSec-compliant devices, such as routers.

Digital signatures, enabled by public key cryptography, provide a means of digitally authenticating devices and individual users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other. In simple terms, a signature is formed when data is encrypted with a user’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. The fact that the message could be decrypted using the sender’s public key indicates that the holder of the private key, the sender, must have created the message. This process relies on the receiver’s having a copy of the sender’s public key and knowing with a high degree of certainty that it does belong to the sender and not to someone pretending to be the sender.

Digital certificates provide the link. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity’s public key. The certificate is itself signed by a CA, a third party that is explicitly trusted by the receiver to validate identities and to create digital certificates.

To validate the signature of the CA, the receiver must first know the CA’s public key. Normally, this process is handled out-of-band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default. IKE, an essential component of IPSec, can use digital signatures to authenticate peer devices for scalability before setting up SAs.

Cisco IOS XR System Security Configuration Guide

SC-3

Information About Implementing Certification Authority

Without digital signatures, a user must manually exchange either public keys or secrets between each pair of devices that use IPSec to protect communication between them. Without certificates, every new device added to the network requires a configuration change on every other device with which it communicates securely. With digital certificates, each device is enrolled with a CA. When two devices want to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new device is added to the network, a user simply enrolls that device with a CA, and none of the other devices needs modification. When the new device attempts an IPSec connection, certificates are automatically exchanged and the device can be authenticated.

IPSec Without CAs

Without a CA, if you want to enable IPSec services (such as encryption) between two Cisco routers, you must first ensure that each router has the key of the other router (such as an RSA public key or a shared key). This requirement means that you must manually perform one of the following operations:

• At each router, enter the RSA public key of the other router.

• At each router, specify a shared key to be used by both routers.

If you have multiple Cisco routers in a mesh topology and want to exchange IPSec traffic passing among all of those routers, you must first configure shared keys or RSA public keys among all of those routers.

Every time a new router is added to the IPSec network, you must configure keys between the new router and each of the existing routers.

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Consequently, the more devices there are that require IPSec services, the more involved the key administration becomes. This approach does not scale well for larger, more complex encrypting networks.

IPSec with CAs

With a CA, you need not configure keys between all the encrypting routers. Instead, you individually enroll each participating router with the CA, requesting a certificate for the router. When this enrollment has been accomplished, each participating router can dynamically authenticate all the other participating routers.

To add a new IPSec router to the network, you need only configure that new router to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPSec routers.

IPSec with Multiple Trustpoint CAs

With multiple trustpoint CAs, you no longer have to enroll a router with the CA that issued a certificate to a peer. Instead, you configure a router with multiple CAs that it trusts. Thus, a router can use a configured CA (a trusted root) to verify certificates offered by a peer that were not issued by the same CA defined in the identity of the router.

Configuring multiple CAs allows two or more routers enrolled under different domains (different CAs) to verify the identity of each other when using IKE to set up IPSec tunnels.

Through SCEP, each router is configured with a CA (the enrollment CA). The CA issues a certificate to the router that is signed with the private key of the CA. To verify the certificates of peers in the same domain, the router is also configured with the root certificate of the enrollment CA.

To verify the certificate of a peer from a different domain, the root certificate of the enrollment CA in the domain of the peer must be configured securely in the router.

Cisco IOS XR System Security Configuration Guide

SC-4

Implementing Certification Authority Interoperability on Cisco IOS XR Software

During IKE phase one signature verification, the initiator will send the responder a list of its CA certificates. The responder should send the certificate issued by one of the CAs in the list. If the certificate is verified, the router saves the public key contained in the certificate on its public key ring.

With multiple root CAs, Virtual Private Network (VPN) users can establish trust in one domain and easily and securely distribute it to other domains. Thus, the required private communication channel between entities authenticated under different domains can occur.

How CA Certificates Are Used by IPSec Devices

When two IPSec routers want to exchange IPSec-protected traffic passing between them, they must first authenticate each other—otherwise, IPSec protection cannot occur. The authentication is done with IKE.

Without a CA, a router authenticates itself to the remote router using either RSA-encrypted nonces or preshared keys. Both methods require keys to have been previously configured between the two routers.

With a CA, a router authenticates itself to the remote router by sending a certificate to the remote router and performing some public key cryptography. Each router must send its own unique certificate that was issued and validated by the CA. This process works because the certificate of each router encapsulates the public key of the router, each certificate is authenticated by the CA, and all participating routers recognize the CA as an authenticating authority. This scheme is called IKE with an RSA signature.

Your router can continue sending its own certificate for multiple IPSec sessions and to multiple IPSec peers until the certificate expires. When its certificate expires, the router administrator must obtain a new one from the CA.

How to Implement CA Interoperability

When your router receives a certificate from a peer from another domain (with a different CA), the certificate revocation list (CRL) downloaded from the CA of the router does not include certificate information about the peer. Therefore, you should check the CRL published by the configured trustpoint with the Lightweight Directory Access Protocol (LDAP) URL to ensure that the certificate of the peer has not been revoked.

To query the CRL published by the configured trustpoint with the LDAP URL, use the query url command in trustpoint configuration mode.

CA Registration Authorities

Some CAs have a registration authority (RA) as part of their implementation. An RA is essentially a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.

How to Implement CA Interoperability

This section contains the following procedures:

• Configuring a Router Hostname and IP Domain Name, page SC-6 (required)

• Generating an RSA Key Pair, page SC-7 (required)

• Declaring a Certification Authority and Configuring a Trusted Point, page SC-8 (required)

• Authenticating the CA, page SC-10 (required)

• Requesting Your Own Certificates, page SC-11 (required)

• Configuring Certificate Enrollment Using Cut-and-Paste, page SC-12

Cisco IOS XR System Security Configuration Guide

SC-5

Implementing Certification Authority Interoperability on Cisco IOS XR Software

How to Implement CA Interoperability

Configuring a Router Hostname and IP Domain Name

This task configures a router hostname and IP domain name.

You must configure the hostname and IP domain name of the router if they have not already been configured. The hostname and IP domain name are required because the router assigns a fully qualified domain name (FQDN) to the keys and certificates used by IPSec, and the FQDN is based on the hostname and IP domain name you assign to the router. For example, a certificate named router20.example.com is based on a router hostname of router20 and a router IP domain name of example.com.

SUMMARY STEPS

1. configure

2. hostname name

3. domain name domain-name

4. end

commit

DETAILED STEPS

Command or Action Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Step 2

hostname

Example:

RP/0/RP0/CPU0:router(config)# hostname myhost

name

Enables global configuration mode.

Configures the hostname of the router.

Cisco IOS XR System Security Configuration Guide

SC-6

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Command or Action Purpose

Step 3

domain name

domain-name

Example:

RP/0/RP0/CPU0:router(config)# domain name mydomain.com

Step 4

end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

How to Implement CA Interoperability

Configures the IP domain name of the router.

Saves configuration changes.

• When you issue the end command, the system prompts

you to commit changes:

Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:

–

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

–

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

–

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Generating an RSA Key Pair

This task generates an RSA key pair.

RSA key pairs are used to sign and encrypt IKE key management messages and are required before you can obtain a certificate for your router.

SUMMARY STEPS

1. crypto key generate rsa [usage keys | general-keys] [keypair-label]

2. crypto key zeroize rsa [keypair-label]

3. show crypto key mypubkey rsa

• Use the commit command to save the configuration

changes to the running configuration file and remain within the configuration session.

Cisco IOS XR System Security Configuration Guide

SC-7

How to Implement CA Interoperability

DETAILED STEPS

Command or Action Purpose

Step 1

crypto key generate rsa [usage keys | general-keys] [

Example:

RP/0/RP0/CPU0:router# crypto key generate rsa general-keys

Step 2

crypto key zeroize rsa [

Example:

RP/0/RP0/CPU0:router# crypto key zeroize rsa key1

Step 3

show crypto key mypubkey rsa

keypair-label

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Generates RSA key pairs.

]

• Use the usage keys keyword to specify special usage

keys; use the general-keys keyword to specify generalpurpose RSA keys.

• The keypair-label argument is the RSA key pair label

that names the RSA key pairs.

]

(Optional) Deletes all RSAs from the router.

• Under certain circumstances, you may want to delete

all RSA keys from you router. For example, if you believe the RSA keys were compromised in some way and should no longer be used, you should delete the keys.

• To remove a specific RSA key pair, use the

keypair-label argument.

(Optional) Displays the RSA public keys for your router.

Example:

RP/0/RP0/CPU0:router# show crypto key mypubkey rsa

Declaring a Certification Authority and Configuring a Trusted Point

This task declares a CA and configures a trusted point.

SUMMARY STEPS

1. configure

2. crypto ca trustpoint ca-name

3. enrollment url CA-URL

4. query url LDAP-URL

5. enrollment retry period minutes

6. enrollment retry count number

7. rsakeypair keypair-label

8. end

commit

Cisco IOS XR System Security Configuration Guide

SC-8

Implementing Certification Authority Interoperability on Cisco IOS XR Software

DETAILED STEPS

Command or Action Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Step 2

crypto ca trustpoint

ca-name

Example:

RP/0/RP0/CPU0:router(config)# crypto ca trustpoint myca

Step 3

enrollment url

CA-URL

Example:

RP/0/RP0/CPU0:router(config-trustp)# enrollment url http://ca.domain.com/certsrv/mscep/mscep.dll

Step 4

query url

LDAP-URL

How to Implement CA Interoperability

Enters global configuration mode.

Declares a CA.

• Configures a trusted point with a selected name so that

your router can verify certificates issued to peers.

• Enters trustpoint configuration mode.

Specifies the URL of the CA.

• The URL should include any nonstandard cgi-bin script

location.

(Optional) Specifies the location of the LDAP server if your CA system supports the LDAP protocol.

Step 5

Step 6

Example:

RP/0/RP0/CPU0:router(config-trustp)# query url ldap://my-ldap.domain.com

enrollment retry period

minutes

Example:

RP/0/RP0/CPU0:router(config-trustp)# enrollment retry period 2

enrollment retry count

number

Example:

RP/0/RP0/CPU0:router(config-trustp)# enrollment retry count 10

(Optional) Specifies a retry period.

• After requesting a certificate, the router waits to receive

a certificate from the CA. If the router does not receive a certificate within a period of time (the retry period) the router will send another certificate request.

• Range is from 1 to 60 minutes. Default is 1 minute.

(Optional) Specifies how many times the router continues to send unsuccessful certificate requests before giving up.

• The range is from 1 to 100.

Cisco IOS XR System Security Configuration Guide

SC-9

How to Implement CA Interoperability

Command or Action Purpose

Step 7

rsakeypair

keypair-label

Implementing Certification Authority Interoperability on Cisco IOS XR Software

(Optional) Specifies a named RSA key pair generated using the crypto key generate rsa command for this trustpoint.

Step 8

Example:

RP/0/RP0/CPU0:router(config-trustp)# rsakeypair mykey

end

commit

Example:

RP/0/RP0/CPU0:router(config-trustp)# end

RP/0/RP0/CPU0:router(config-trustp)# commit

• Not setting this key pair means that the trustpoint uses

the default RSA key in the current configuration.

Saves configuration changes.

• When you issue the end command, the system prompts

you to commit changes:

Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:

–

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

–

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

–

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

• Use the commit command to save the configuration

changes to the running configuration file and remain within the configuration session.

Authenticating the CA

This task authenticates the CA to your router.

The router must authenticate the CA by obtaining the self-signed certificate of the CA, which contains the public key of the CA. Because the certificate of the CA is self-signed (the CA signs its own certificate), manually authenticate the public key of the CA by contacting the CA administrator to compare the fingerprint of the CA certificate.

SUMMARY STEPS

1. crypto ca authenticate ca-name

2. show crypto ca certificates

Cisco IOS XR System Security Configuration Guide

SC-10

Implementing Certification Authority Interoperability on Cisco IOS XR Software

DETAILED STEPS

Command or Action Purpose

Step 1

crypto ca authenticate

ca-name

Example:

RP/0/RP0/CPU0:router# crypto ca authenticate myca

Step 2

show crypto ca certificates

Example:

RP/0/RP0/CPU0:router# show crypto ca certificates

Requesting Your Own Certificates

How to Implement CA Interoperability

Authenticates the CA to your router by obtaining a CA certificate, which contains the public key for the CA.

(Optional) Displays information about the CA certificate.

SUMMARY STEPS

This task requests certificates from the CA.

You must obtain a signed certificate from the CA for each of your router’s RSA key pairs. If you generated general-purpose RSA keys, your router has only one RSA key pair and needs only one certificate. If you previously generated special usage RSA keys, your router has two RSA key pairs and needs two certificates.

1. crypto ca enroll ca-name

2. show crypto ca certificates

Cisco IOS XR System Security Configuration Guide

SC-11

How to Implement CA Interoperability

DETAILED STEPS

Command or Action Purpose

Step 1

crypto ca enroll

Example:

RP/0/RP0/CPU0:router# crypto ca enroll myca

Step 2

show crypto ca certificates

ca-name

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Requests certificates for all of your RSA key pairs.

• This command causes your router to request as many

certificates as there are RSA key pairs, so you need only perform this command once, even if you have special usage RSA key pairs.

• This command requires you to create a challenge

password that is not saved with the configuration. This password is required if your certificate needs to be revoked, so you must remember this password.

• A certificate may be issued immediately or the router

sends a certificate request every minute until the enrollment retry period is reached and a timeout occurs. If a timeout occurs, contact your system administrator to get your request approved, and then enter this command again.

(Optional) Displays information about the CA certificate.

Example:

RP/0/RP0/CPU0:router# show crypto ca certificates

Configuring Certificate Enrollment Using Cut-and-Paste

This task declares the trustpoint certification authority (CA) that your router should use and configures that trustpoint CA for manual enrollment by using cut-and-paste.

SUMMARY STEPS

1. configure

2. crypto ca trustpoint ca-name

3. enrollment terminal

4. end

commit

5. crypto ca authenticate ca-name

6. crypto ca enroll ca-name

7. crypto ca import ca-name certificate

8. show crypto ca certificates

Cisco IOS XR System Security Configuration Guide

SC-12

Implementing Certification Authority Interoperability on Cisco IOS XR Software

DETAILED STEPS

Command or Action Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Step 2

crypto ca trustpoint

ca-name

How to Implement CA Interoperability

Enters global configuration mode.

Declares the CA that your router should use and enters trustpoint configuration mode.

Step 3

Step 4

Example:

RP/0/RP0/CPU0:router(config)# crypto ca trustpoint myca RP/0/RP0/CPU0:router(config-trustp)#

enrollment terminal

Example:

RP/0/RP0/CPU0:router(config-trustp)# enrollment terminal

end

commit

Example:

RP/0/RP0/CPU0:router(config-trustp)# end

RP/0/RP0/CPU0:router(config-trustp)# commit

• Use the ca-name argument to specify the name

of the CA.

Specifies manual cut-and-paste certificate enrollment.

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:

–

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

–

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Step 5

crypto ca authenticate

ca-name

Example:

RP/0/RP0/CPU0:router# crypto ca authenticate myca

–

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running configuration file and remain within the configuration session.

Authenticates the CA by obtaining the certificate of the CA.

• Use the ca-name argument to specify the name

of the CA. Use the same name that you entered in Step 2.

Cisco IOS XR System Security Configuration Guide

SC-13

Configuration Examples for Implementing Certification Authority Interoperability

Command or Action Purpose

Step 6

crypto ca enroll

ca-name

Example:

RP/0/RP0/CPU0:router# crypto ca enroll myca

Step 7

crypto ca import ca-

name

certificate

Example:

RP/0/RP0/CPU0:router# crypto ca import myca certificate

Step 8

show crypto ca certificates

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Obtains the certificates for your router from the CA.

• Use the ca-name argument to specify the name

of the CA. Use the same name that you entered in Step 2.

Imports a certificate manually at the terminal.

• Use the ca-name argument to specify the name

of the CA. Use the same name that you entered in Step 2.

Note You must enter the crypto ca import

command twice if usage keys (signature and encryption keys) are used. The first time the command is entered, one of the certificates is pasted into the router; the second time the command is entered, the other certificate is pasted into the router. (It does not matter which certificate is pasted first.

Displays information about your certificate and the CA certificate.

Example:

RP/0/RP0/CPU0:router# show crypto ca certificates

Configuration Examples for Implementing Certification Authority Interoperability

This section provides the following configuration example:

• Configuring Certification Authority Interoperability: Example, page SC-14

Configuring Certification Authority Interoperability: Example

The following example shows how to configure CA interoperability.

Comments are included within the configuration to explain various commands.

configure hostname myrouter domain name mydomain.com end

Uncommitted changes found, commit them? [yes]:yes

crypto key generate rsa mykey

The name for the keys will be:mykey Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keypair Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [1024]: Generating RSA keys ...

Cisco IOS XR System Security Configuration Guide

SC-14

Implementing Certification Authority Interoperability on Cisco IOS XR Software

Configuration Examples for Implementing Certification Authority Interoperability

Done w/ crypto generate keypair [OK]

show crypto key mypubkey rsa

Key label:mykey Type :RSA General purpose Size :1024 Created :17:33:23 UTC Thu Sep 18 2003 Data : 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00CB8D86 BF6707AA FD7E4F08 A1F70080 B9E6016B 8128004C B477817B BCF35106 BC60B06E 07A417FD 7979D262 B35465A6 1D3B70D1 36ACAFBD 7F91D5A0 CFB0EE91 B9D52C69 7CAF89ED F66A6A58 89EEF776 A03916CB 3663FB17 B7DBEBF8 1C54AF7F 293F3004 C15B08A8 C6965F1E 289DD724 BD40AF59 E90E44D5 7D590000 5C4BEA9D B5020301 0001

! The following commands declare a CA and configure a trusted point.

configure crypto ca trustpoint myca

enrollment url http://xyz-ultra5 enrollment retry count 25 enrollment retry period 2 rsakeypair mykey end

Uncommitted changes found, commit them? [yes]:yes

! The following command authenticates the CA to your router.

crypto ca authenticate myca

Serial Number :01 Subject Name :

cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US

Issued By :

cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US Validity Start :07:00:00 UTC Tue Aug 19 2003 Validity End :07:00:00 UTC Wed Aug 19 2020 Fingerprint:58 71 FB 94 55 65 D4 64 38 91 2B 00 61 E9 F8 05 Do you accept this certificate?? [yes/no]:yes

! The following command requests certificates for all of your RSA key pairs.

crypto ca enroll myca

% Start certificate enrollment ... % Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. % For security reasons your password will not be saved in the configuration. % Please make a note of it.

Password: Re-enter Password: Fingerprint: 17D8B38D ED2BDF2E DF8ADBF7 A7DBE35A

! The following command displays information about your certificate and the CA certificate.

show crypto ca certificates

Trustpoint :myca ==========================================================

Cisco IOS XR System Security Configuration Guide

SC-15

Where to Go Next

Implementing Certification Authority Interoperability on Cisco IOS XR Software

CA certificate Serial Number :01 Subject Name : cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US Issued By : cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US Validity Start :07:00:00 UTC Tue Aug 19 2003 Validity End :07:00:00 UTC Wed Aug 19 2020 Router certificate Key usage :General Purpose Status :Available Serial Number :6E Subject Name : unstructuredName=myrouter.mydomain.com,o=Cisco Systems Issued By : cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US Validity Start :21:43:14 UTC Mon Sep 22 2003 Validity End :21:43:14 UTC Mon Sep 29 2003 CRL Distribution Point ldap://coax-u10.cisco.com/CN=Root coax-u10 Certificate Manager,O=Cisco Systems

Where to Go Next

After you have finished configuring CA interoperability, you should configure IKE, IPSec, and SSL. IKE configuration is described in the Implementing Internet Key Exchange Security Protocol on

Cisco IOS XR Software module, IPSec in the Implementing IPSec Network Security on Cisco IOS XR Software module, and SSL in the Implementing Secure Socket Layer on Cisco IOS XR Software module. These modules are located in Cisco IOS XR System Security Configuration Guide.

Additional References

The following sections provide references related to implementing certification authority interoperability.

Cisco IOS XR, IOS XR 3.5 Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual