The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This module describes how to implement keychain management on Cisco 8000 Series Routers. Keychain management is a common method of authentication to configure shared secrets on all entities that exchange secrets such as keys, before establishing trust with each other. Routing protocols and network management applications on Cisco IOS XR software often use authentication to enhance security while communicating with peers.
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
You must be aware that changing the system clock impacts the validity of the keys in the existing configuration.
The keychain by itself has no relevance; therefore, it must be used by an application that needs to communicate by using the keys (for authentication) with its peers. The keychain provides a secure mechanism to handle the keys and rollover based on the lifetime. Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Intermediate System-to-Intermediate System (IS-IS) use the keychain to implement a hitless key rollover for authentication. BGP uses TCP authentication, which enables the authentication option and sends the Message Authentication Code (MAC) based on the cryptographic algorithm configured for the keychain. For information about BGP, OSPF, and IS-IS keychain configurations, see the Configure>Routing end-user guide listed here.
Resource Reservation Protocol (RSVP) uses keychain for authentication.
For more information about RSVP, see the Configure>MPLS end-user guide listed here.
IP Service Level Agreements (IP SLAs) use a keychain for MD5 authentication for the IP SLA control message. For more information about IP SLAs, see the Configure>System Monitoring end-user guide listed here.
To implement keychain management, you must understand the concept of key lifetime, which is explained in the next section.
If you are using keys as the security method, you must specify the lifetime for the keys and change the keys on a regular basis when they expire. To maintain stability, each party must be able to store and use more than one key for an application at the same time. A keychain is a sequence of keys that are collectively managed for authenticating the same peer, peer group, or both.
Keychain management groups a sequence of keys together under a keychain and associates each key in the keychain with a lifetime.
 Note |
Any key that is configured without a lifetime is considered invalid; therefore, the key is rejected during configuration. |
The lifetime of a key is defined by the following options:
Start-time—Specifies the absolute time.
End-time—Specifies the absolute time that is relative to the start-time or infinite time.
Each key definition within the keychain must specify a time interval for which that key is activated; for example, lifetime. Then, during a given key's lifetime, routing update packets are sent with this activated key. Keys cannot be used during time periods for which they are not activated. Therefore, we recommend that for a given keychain, key activation times overlap to avoid any period of time for which no key is activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur; therefore, routing updates can fail.
Multiple keychains can be specified.
This section contains the following procedures:
This task configures a name for the keychain.
You can create or modify the name of the keychain.
|
Step 1 |
configure Example:Enters mode. |
||
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain.
|
||
|
Step 3 |
commit Commits the configuration changes and remains within the configuration session. |
||
|
Step 4 |
show key chain key-chain-name Example:(Optional) Displays the name of the keychain.
|
||
|
Step 5 |
show run Example: |
This task configures the tolerance specification to accept keys for a keychain to facilitate a hitless key rollover for applications, such as routing and management protocols.
|
Step 1 |
configure Example:Enters mode. |
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain. |
|
Step 3 |
accept-tolerance value [infinite] Example:Configures an accept tolerance limit—duration for which an expired or soon-to-be activated keys can be used for validating received packets—for a key that is used by a peer.
|
|
Step 4 |
commit Commits the configuration changes and remains within the configuration session. |
This task configures a key identifier for the keychain.
You can create or modify the key for the keychain.
|
Step 1 |
configure Example:Enters mode. |
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain. |
|
Step 3 |
key key-id Example:Creates a key for the keychain. The key ID has to be unique within the specific keychain.
|
|
Step 4 |
commit Commits the configuration changes and remains within the configuration session. |
This task configures the text for the key string.
|
Step 1 |
configure Example:Enters mode. |
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain. |
|
Step 3 |
key key-id Example:Creates a key for the keychain. |
|
Step 4 |
key-string [clear | password] key-string-text Example:Specifies the text string for the key.
|
|
Step 5 |
commit Commits the configuration changes and remains within the configuration session. |
This task determines the valid keys for local applications to authenticate the remote peers.
|
Step 1 |
configure Example:Enters mode. |
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain. |
|
Step 3 |
key key-id Example:Creates a key for the keychain. |
|
Step 4 |
accept-lifetime start-time [duration duration-value | infinite | end-time] Example:(Optional) Specifies the validity of the key lifetime in terms of clock time. You can specify the start-time and end-time in hh:mm:ss month DD YYYY format or hh:mm:ss DD month YYYY format. |
|
Step 5 |
commit Commits configuration changes and exits the configuration session. |
This task configures the keys to generate authentication digest for the outbound application traffic.
|
Step 1 |
configure Example:Enters mode. |
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain. |
|
Step 3 |
key key-id Example:Creates a key for the keychain. |
|
Step 4 |
send-lifetime start-time [duration duration-value | infinite | end-time] Example:(Optional) Specifies the set time period during which an authentication key on a keychain is valid to be sent. You can specify the validity of the key lifetime in terms of clock time. In addition, you can specify a start-time value and one of the following values:
If you intend to set lifetimes on keys, Network Time Protocol (NTP) or some other time synchronization method is recommended. |
|
Step 5 |
commit Commits the configuration changes and remains within the configuration session. |
This task allows the keychain configuration to accept the choice of the cryptographic algorithm.
From Cisco IOS XR Software Release 7.2.1 and later, you must follow the below guidelines while configuring the key chain. These are applicable only for FIPS mode (that is, when crypto fips-mode is configured).
You must configure the session with a FIPS-approved cryptographic algorithm. A session configured with non-approved cryptographic algorithm for FIPS (such as, MD5 and HMAC-MD5 ) does not work. This is applicable for OSPF, BGP, RSVP, ISIS, or any application using key chain with non-approved cryptographic algorithm.
If you are using any HMAC-SHA algorithm for a session, then you must ensure that the configured key-string has a minimum length of 14 characters. Otherwise, the session goes down.
|
Step 1 |
configure Example:Enters mode. |
|
Step 2 |
key chain key-chain-name Example:Creates a name for the keychain. |
|
Step 3 |
key key-id Example:Creates a key for the keychain. |
|
Step 4 |
cryptographic-algorithm [HMAC-MD5 | HMAC-SHA1-12 | HMAC-SHA1-20 | MD5 | SHA-1 | AES-128-CMAC-96 | HMAC-SHA-256 | HMAC-SHA1-96] Example:Specifies the choice of the cryptographic algorithm. You can choose from the following list of algorithms:
The routing protocols each support a different set of cryptographic algorithms:
|
|
Step 5 |
commit Commits configuration changes and exits the configuration session |
This section provides the following configuration example:
The following example shows how to configure keychain management:
configure
key chain isis-keys
accept-tolerance infinite
key 8
key-string mykey91abcd
cryptographic-algorithm MD5
send-lifetime 1:00:00 june 29 2006 infinite
accept-lifetime 1:00:00 june 29 2006 infinite
Router#show key chain isis-keys
Key-chain: isis-keys/ -
accept-tolerance -- infinite
Key 8 -- text "1104000E120B520005282820"
cryptographic-algorithm -- MD5
Send lifetime: 01:00:00, 29 Jun 2006 - Always valid [Valid now]
Accept lifetime: 01:00:00, 29 Jun 2006 - Always valid [Valid now]
Feedback