To enable the authentication, authorization, and accounting (AAA) access control model, use the aaa new-model command in global configuration mode. To disable the AAA access control model, use the no form of this command.

aaa new-model

no aaa new-model

This command has no arguments or keywords.

Command Default: AAA is not enabled.

Command Mode: Global configuration (config)

Usage Guidelines: This command enables the AAA access control system.

To set authentication, authorization, and accounting (AAA) authentication at login, use the aaa authentication login command in global configuration mode. To disable AAA authentication, use the no form of this command.

aaa authentication login {default | list-name } method1 [method2...]

no aaa authentication login {default | list-name } method1 [method2...]

Command Default: AAA authentication at login is disabled.

Command Mode: Global configuration (config)

Usage Guidelines: If the default keyword is not set, only the local user database is checked. This has the same effect as the following command:

aaa authentication login default local

On the console, login will succeed without any authentication checks if default keyword is not set.

The default and optional list names that you create with the aaa authentication login command are used with the login authentication command.

Create a list by entering the aaa authentication login list-name method command for a particular protocol. The list-name argument is the character string used to name the list of authentication methods activated when a user logs in. The method argument identifies the list of methods that the authentication algorithm tries, in the given sequence. The “Authentication Methods that cannot be used for the list-name Argument” section lists authentication methods that cannot be used for the list-name argument and the table below describes the method keywords.

To create a default list that is used if no list is assigned to a line, use the login authentication command with the default argument followed by the methods you want to use in default situations.

The password is prompted only once to authenticate the user credentials and in case of errors due to connectivity issues, multiple retries are possible through the additional methods of authentication. However, the switchover to the next authentication method happens only if the previous method returns an error, not if it fails. To ensure that the authentication succeeds even if all methods return an error, specify none as the final method in the command line.

If authentication is not specifically set for a line, the default is to deny access and no authentication is performed. Use the more system:running-config command to display currently configured lists of authentication methods.

Authentication Methods that cannot be used for the list-name Argument

The authentication methods that cannot be used for the list-name argument are as follows:

• auth-guest

• enable

• guest

• if-authenticated

• if-needed

• krb5

• krb-instance

• krb-telnet

• line

• local

• none

• radius

• rcmd

• tacacs

• tacacsplus

In the table below, the group radius, group tacacs +, group ldap, and group group-name methods refer to a set of previously defined RADIUS or TACACS+ servers. Use the radius-server host and tacacs-server host commands to configure the host servers. Use the aaa group server radius, aaa group server ldap, and aaa group server tacacs+ commands to create a named group of servers.

The table below describes the method keywords.

Keyword	Description
cache group-name	Uses a cache server group for authentication.
enable	Uses the enable password for authentication. This keyword cannot be used.
group group-name	Uses a subset of RADIUS or TACACS+ servers for authentication as defined by the aaa group server radius or aaa group server tacacs+ command.
group ldap	Uses the list of all Lightweight Directory Access Protocol (LDAP) servers for authentication.
group radius	Uses the list of all RADIUS servers for authentication.
group tacacs+	Uses the list of all TACACS+ servers for authentication.
krb5	Uses Kerberos 5 for authentication.
krb5-telnet	Uses Kerberos 5 Telnet authentication protocol when using Telnet to connect to the router.
line	Uses the line password for authentication.
local	Uses the local username database for authentication.
local-case	Uses case-sensitive local username authentication.
none	Uses no authentication.
passwd-expiry	Enables password aging on a local authentication list.   The radius-server vsa send authentication command is required to make the passwd-expiry keyword work.

To set the parameters that restrict user access to a network, use the aaa authorization command in global configuration mode. To remove the parameters, use the no form of this command.

aaa authorization { auth-proxy | cache | commandslevel | config-commands | configuration | console | exec | ipmobile | multicast | network | policy-if | prepaid | radius-proxy | reverse-access | subscriber-service | template} {default | list-name } [method1 [method2.… ]]

no aaa authorization { auth-proxy | cache | commandslevel | config-commands | configuration | console | exec | ipmobile | multicast | network | policy-if | prepaid | radius-proxy | reverse-access | subscriber-service | template} {default | list-name } [method1 [method2.… ]]

Command Default: Authorization is disabled for all actions (equivalent to the method keyword none ).

Command Mode: Global configuration (config)

Usage Guidelines: Use the aaa authorization command to enable authorization and to create named methods lists, which define authorization methods that can be used when a user accesses the specified function. Method lists for authorization define the ways in which authorization will be performed and the sequence in which these methods will be performed. A method list is a named list that describes the authorization methods (such as RADIUS or TACACS+) that must be used in sequence. Method lists enable you to designate one or more security protocols to be used for authorization, thus ensuring a backup system in case the initial method fails. Cisco IOS software uses the first method listed to authorize users for specific network services; if that method fails to respond, the Cisco IOS software selects the next method listed in the method list. This process continues until there is successful communication with a listed authorization method, or until all the defined methods are exhausted.

The Cisco IOS software attempts authorization with the next listed method only when there is no response from the previous method. If authorization fails at any point in this cycle--meaning that the security server or the local username database responds by denying the user services--the authorization process stops and no other authorization methods are attempted.

If the aaa authorization command for a particular authorization type is issued without a specified named method list, the default method list is automatically applied to all interfaces or lines (where this authorization type applies) except those that have a named method list explicitly defined. (A defined method list overrides the default method list.) If no default method list is defined, then no authorization takes place. The default authorization method list must be used to perform outbound authorization, such as authorizing the download of IP pools from the RADIUS server.

Use the aaa authorization command to create a list by entering the values for the list-name and the method arguments, where list-name is any character string used to name this list (excluding all method names) and method identifies the list of authorization methods tried in the given sequence.

The aaa authorization command supports 13 separate method lists. For example:

aaa authorization configuration methodlist1 group radius

aaa authorization configuration methodlist2 group radius

...

aaa authorization configuration methodlist13 group radius

In the table below, the group group-name, group ldap, group radius , and group tacacs + methods refer to a set of previously defined RADIUS or TACACS+ servers. Use the radius-server host and tacacs-server host commands to configure the host servers. Use the aaa group server radius , aaa group server ldap , and aaa group server tacacs+ commands to create a named group of servers.

Cisco IOS software supports the following methods for authorization:

• Cache Server Groups--The router consults its cache server groups to authorize specific rights for users.

• If-Authenticated --The user is allowed to access the requested function provided the user has been authenticated successfully.

• Local --The router or access server consults its local database, as defined by the username command, to authorize specific rights for users. Only a limited set of functions can be controlled through the local database.

• None --The network access server does not request authorization information; authorization is not performed over this line or interface.

• RADIUS --The network access server requests authorization information from the RADIUS security server group. RADIUS authorization defines specific rights for users by associating attributes, which are stored in a database on the RADIUS server, with the appropriate user.

• TACACS+ --The network access server exchanges authorization information with the TACACS+ security daemon. TACACS+ authorization defines specific rights for users by associating attribute-value (AV) pairs, which are stored in a database on the TACACS+ security server, with the appropriate user.

To allow connections between specific types of endpoints in a VoIP network, use the allow-connections command in voice service configuration mode. To refuse specific types of connections, use the no form of this command.

allow-connections from-type to to-type

no allow-connections from-type to to-type

Command Default: SIP-to-SIP connections are disabled by default.

Command Mode: Voice-service configuration (config-voi-serv)

Usage Guidelines: This command is used to allow connections between specific types of endpoints in a Cisco multiservice IP-to-IP gateway. The command is enabled by default and cannot be changed.

To allow the insertion of '#' at any place in voice register dn, use the allow-hash-in-dn command in voice register global mode. To disable this, use the no form of this command.

allow-hash-in-dn

no allow-hash-in-dn

Command Default: The command is disabled by default.

Command Mode: voice register global configuration (config-register-global)

Usage Guidelines: Before this command was introduced, the characters supported in voice register dn were 0-9, +, and *. The new command is enabled whenever the user requires the insertion of # in voice register dn. The command is disabled by default. You can configure this command only in Cisco Unified SRST and Cisco Unified E-SRST modes. The character # can be inserted at any place in voice register dn. When this command is enabled, users are required to change the default termination character(#) to another valid character using dial-peer terminator command under configuration mode.

To enter redundancy application configuration mode, use the application redundancy command in redundancy configuration mode.

application redundancy

This command has no arguments or keywords.

Command Default: None

Command Mode: Redundancy configuration (config-red)

Usage Guidelines: Use this application redundancy command to configure application redundancy for high availability.

To set the default gateway for an application, use the app-default-gateway command in application hosting configuration mode. To remove the default gatway, use the no form of this command.

app-default-gateway [ip-address guest-interface network-interface-number]

no app-default-gateway [ip-address guest-interface network-interface-number]

Command Default: The default gateway is not configured.

Command Mode: Application hosting configuration (config-app-hosting)

Usage Guidelines: Use the app-default-gateway command to set default gateway for an application. The gateway connectors are applications installed on the Cisco IOS XE GuestShell container.

To configure an application, and to enter application hosting configuration mode, use the app-hosting appid command in global configuration mode. To remove the application, use the no form of this command.

app-hosting appid application-name

Command Default: No application is configured.

Command Mode: Global configuration (config)

Usage Guidelines:The application name argument can be up to 32 alphanumeric characters.

You can update the application hosting configuration, after configuring this command.

To override the application-provided resource profile, use the app-resoure profile command in application hosting configuration mode. To revert to the application-specified resource profile, use the no form of this command.

app-resoure profile profile-name

no app-resoure profile profile-name

Command Default: Resource profile is configured.

Command Mode: Application hosting configuration (config-app-hosting)

Usage Guidelines: Reserved resources specified in the application package can be changed by setting a custom resource profile. Only the CPU, memory, and virtual CPU (vCPU) resources can be changed. For the resource changes to take effect, stop and deactivate the application, then activate and start it again.

Only custom profile is supported.

The command configures the custom application resource profile, and enters custom application resource profile configuration mode.

To configure a virtual network interface gateway for an application, use the app-vnic gateway command in application hosting configuration mode. To remove the configuration, use the no form of this command.

This command is supported only on routing platforms. It is not supported on switching platforms.

app-vnic gateway virtualportgroup number guest-interface network-interface-number

no app-vnic gateway virtualportgroup number guest-interface network-interface-number

Command Default: The virtual network gateway is not configured.

Command Mode: Application hosting configuration (config-app-hosting)

Usage Guidelines: After you configure the virtual network interface gateway for an application, the command mode changes to application-hosting gateway configuration mode. In this mode, you can configure the IP address of the guest interface.

To enable support for the asserted ID header in incoming Session Initiation Protocol (SIP) requests or response messages, and to send the asserted ID privacy information in outgoing SIP requests or response messages, use the asserted-id command in voice service VoIP-SIP configuration mode or voice class tenant configuration mode. To disable the support for the asserted ID header, use the no form of this command.

asserted-id { pai | ppi } system

no asserted-id { pai | ppi } system

Command Default: The privacy information is sent using the Remote-Party-ID (RPID) header or the FROM header.

Command Mode: Voice service VoIP-SIP configuration (conf-serv-sip) and Voice class tenant configuration (config-class)

Usage Guidelines: If you choose the pai keyword or the ppi keyword, the gateway builds the PAI header or the PPI header, respectively, into the common SIP stack. The pai keyword or the ppi keyword has the priority over the Remote-Party-ID (RPID) header, and removes the RPID header from the outbound message, even if the router is configured to use the RPID header at the global level.

To configure Session Initiation Protocol (SIP) asymmetric payload support, use the asymmetric payload command in SIP configuration mode or voice class tenant configuration mode. To disable asymmetric payload support, use the no form of this command.

asymmetricpayload { dtmf | dynamic-codecs | full | system }

no asymmetricpayload { dtmf | dynamic-codecs | full | system }

Command Default: This command is disabled.

Command Mode: Voice service SIP configuration (conf-serv-sip), Voice class tenant configuration (config-class)

Usage Guidelines: Enter SIP configuration mode from voice-service configuration mode, as shown in the example.

For the Cisco UBE the SIP asymmetric payload-type is supported for audio/video codecs, DTMF, and NSE. Hence, dtmf and dynamic-codecs keywords are internally mapped to the full keyword to provide asymmetric payload-type support for audio/video codecs, DTMF, and NSE.

To enable SIP digest authentication on an individual dial peer, use the authentication command in dial peer voice configuration mode. To disable SIP digest authentication, use the no form of this command.

authentication username username password { 0 | 6 | 7 } password [realm realm | challenge | all ]

no authentication username username password { 0 | 6 | 7 } password [realm realm | challenge | all ]

Command Default: SIP digest authentication is disabled.

Command Mode: Dial peer voice configuration (config-dial-peer)

Usage Guidelines: The following configuration rules are applicable when enabling digest authentication:

• Only one username can be configured per dial peer. Any existing username configuration must be removed before configuring a different username.

• A maximum of five password or realm arguments can be configured for any one username.

The username and password arguments are used to authenticate a user. An authenticating server/proxy issuing a 407/401 challenge response includes a realm in the challenge response and the user provides credentials that are valid for that realm. Because it is assumed that a maximum of five proxy servers in the signaling path can try to authenticate a given request from a user-agent client (UAC) to a user-agent server (UAS), a user can configure up to five password and realm combinations for a configured username.

The user provides the password in plain text but it is encrypted and saved for 401 challenge response. If the password is not saved in encrypted form, a junk password is sent and the authentication fails.

• The realm specification is optional. If omitted, the password configured for that username applies to all realms that attempt to authenticate.

• Only one password can be configured at a time for all configured realms. If a new password is configured, it overwrites any previously configured password.

This means that only one global password (one without a specified realm) can be configured. If you configure a new password without configuring a corresponding realm, the new password overwrites the previous one.

• If a realm is configured for a previously configured username and password, that realm specification is added to that existing username and password configuration. However, once a realm is added to a username and password configuration, that username and password combination is valid only for that realm. A configured realm cannot be removed from a username and password configuration without first removing the entire configuration for that username and password--you can then reconfigure that username and password combination with or without a different realm.

• In an entry with both a password and realm, you can change either the password or realm.

• Use the no authentication all command to remove all the authentication entries for the user.

It is mandatory to specify the encryption type for the password. If a clear text password (type 0) is configured, it is encrypted as type 6 before saving it to the running configuration.

If you specify the encryption type as 6 or 7, the entered password is checked against a valid type 6 or 7 password format and saved as type 6 or 7 respectively.

Type-6 passwords are encrypted using AES cipher and a user-defined primary key. These passwords are comparatively more secure. The primary key is never displayed in the configuration. Without the knowledge of the primary key, type 6 passwords are unusable. If the primary key is modified, the password that is saved as type 6 is re-encrypted with the new primary key. If the primary key configuration is removed, the type 6 passwords cannot be decrypted, which may result in the authentication failure for calls and registrations.

When backing up a configuration or migrating the configuration to another device, the primary key is not dumped. Hence the primary key must be configured again manually.

To configure an encrypted preshared key, see Configuring an Encrypted Preshared Key.

Following warning message is displayed when encryption type 7 is configured. Warning: Command has been added to the configuration using a type 7 password. However, type 7 passwords will soon be deprecated. Migrate to a supported password type 6.

To bind the source address for signaling and media packets to the IPv4 or IPv6 address of a specific interface, use the bind command in SIP configuration mode. To disable binding, use the no form of this command.

bind { control | media | all } source-interface interface-id { ipv4-address ipv4-address | ipv6-address ipv6-address }

no bind { control | media | all } source-interface interface-id { ipv4-address ipv4-address | ipv6-address ipv6-address }

Command Default: Binding is disabled.

Command Mode: SIP configuration (conf-serv-sip) and Voice class tenant.

Usage Guidelines: Async, Ethernet, FastEthernet, Loopback, and Serial (including Frame Relay) are interfaces within the SIP application.

If the bind command is not enabled, the IPv4 layer still provides the best local address.

To enable the basic configurations for Call-Home, use the call-home reporting command in global configuration mode.

call-home reporting { anonymous | contact-email-addr } [ http-proxy { ipv4-address | ipv6-address | name } port port-number ]

Command Default: No default behavior or values

Command Mode: Global configuration (config)

Usage Guidelines: After successfully enabling Call-Home either in anonymous or full registration mode using the call-home reporting command, an inventory message is sent out. If Call-Home is enabled in full registration mode, a full inventory message for full registration mode is sent out. If Call-Home is enabled in anonymous mode, an anonymous inventory message is sent out. For more information about the message details, see Alert Group Trigger Events and Commands.

To enable Cisco Unified SRST support and enter call-manager-fallback configuration mode, use the call-manager-fallback command in global configuration mode. To disable Cisco Unified SRST support, use the no form of this command.

call-manager-fallback

no call-manager-fallback

This command has no arguments or keywords.

Command Default: No default behavior or values.

Command Mode: Global configuration

To enable server, client, or bidirectional identity validation of a peer certificate during TLS handshake, use the command cn-san validate in voice class tls-profile configuration mode. To disable certificate identity validation, use no form of this command.

cn-san validate { server | client | bidirectional }

no cn-san validate { server | client | bidirectional }

Command Default: Identity validation is disabled.

Command Mode: Voice class configuration (config-class)

Usage Guidelines: Server identity validation is associated with a secure signaling connection through the global crypto signaling and voice class tls-profile configurations.

The command is enhanced to include the client and bidirectional keywords. The client option allows a server to validate the identity of a client by checking CN and SAN hostnames included in the provided certificate against a trusted list of cn-san FQDNs. The connection will only be established if a match is found. This list of cn-san FQDNs is also now used to validate a server certificate, in addition to the session target host name. The bidirectional option validates peer identity for both client and server connections by combining both server and client modes. Once you configure cn-san validate, the identity of the peer certificate is validated for every new TLS connection.

To configure a list of Fully Qualified Domain Name (FQDN) name to validate against the peer certificate for inbound or outbound TLS connections, use the cn-san command in voice class tls-profile configuration mode. To delete cn-san certificate validation entry, use the no form of this command.

cn-san {1-10} fqdn

no cn-san {1-10} fqdn

Command Default: No cn-san names are configured.

Command Mode: Voice class tls-profile configuration mode (config-class)

Usage Guidelines: FQDN used for peer certificate validation are assigned to a TLS profile with up to ten cn-san entries. At least one of these entries must be matched to an FQDN in either of the certificate Common Name (CN) or Subject-Alternate-Name (SAN) fields before a TLS connection is established. To match any domain host used in an CN or SAN field, a cn-san entry may be configured with a domain wildcard, strictly in the form *.domain-name (e.g. *.cisco.com). No other use of wildcards is permitted.

For inbound connections, the list is used to validate CN and SAN fields in the client certificate. For outbound connections, the list is used along with the session target hostname to validate CN and SAN fields in the server certificate.

Server certificates may also be verified by matching the SIP session target FQDN to a CN or SAN field.

To specify a list of preferred codecs to use on a dial peer, use the codec preference command in voice class configuration mode. To disable this functionality, use the no form of this command.

codec preference value codec-type

no codec preference value codec-type

Command Default: If this command is not entered, no specific types of codecs are identified with preference.

Command Mode: voice class configuration (config-class)

Usage Guidelines: The routers at opposite ends of the WAN may have to negotiate the codec selection for the network dial peers. The codec preference command specifies the order of preference for selecting a negotiated codec for the connection. The table below describes the voice payload options and default values for the codecs and packet voice protocols.

To use global listener port for sending requests over UDP, use the connection-reuse command in sip-ua mode or voice class tenant configuration mode. To disable, use no form of this command.

connection-reuse { via-port | system }

no connection-reuse { via-port | system }

Command Default: Local Gateway uses an ephemeral UDP port for sending requests over UDP.

Command Modes: SIP UA configuration (config-sip-ua), voice class tenant configuration (config-class)

Usage Guidelines: Executing this command enables the use listener port for sending requests over UDP. Default listener port for regular non-secure SIP is 5060 and secure SIP is 5061. Configure listen-port [non-secure | secure] port command in voice service voip > sip configuration mode to change the global UDP port.

To change the CPU quota or unit allocated for an application, use the cpu command in custom application resource profile configuration mode. To revert to the application-provided CPU quota, use the no form of this command.

cpu unit

no cpu unit

Command Default: Default CPU depends on the platform.

Command Mode: Custom application resource profile configuration (config-app-resource-profile-custom)

Usage Guidelines: A CPU unit is the minimal CPU allocation by the application. Total CPU units is based on normalized CPU units measured for the target device.

Within each application package, an application-specific resource profile is provided that defines the recommended CPU load, memory size, and number of virtual CPUs (vCPUs) required for the application. Use this command to change the allocation of resources for specific processes in the custom resource profile.

Reserved resources specified in the application package can be changed by setting a custom resource profile. Only the CPU, memory, and vCPU resources can be changed. For the resource changes to take effect, stop and deactivate the application, then activate it and start it again.

Resource values are application-specific, and any adjustment to these values must ensure that the application can run reliably with the changes.

To configure a Cisco IOS Session Initiation Protocol (SIP) time-division multiplexing (TDM) gateway, a Cisco Unified Border Element (Cisco UBE), or Cisco Unified Communications Manager Express (Cisco Unified CME) to send a SIP registration message when in the UP state, use the credentials command in SIP UA configuration mode or voice class tenant configuration mode. To disable SIP digest credentials, use the no form of this command.

credentials { dhcp | number number username username } password { 0 | 6 | 7 } password realm realm

no credentials { dhcp | number number username username } password { 0 | 6 | 7 } password realm realm

Command Default: SIP digest credentials are disabled.

Command Mode: SIP UA configuration (config-sip-ua) and Voice class tenant configuration (config-class).

Usage Guidelines: The following configuration rules are applicable when credentials are enabled:

• Only one password is valid for all domain names. A new configured password overwrites any previously configured password.

• The password will always be displayed in encrypted format when the credentials command is configured and the show running-config command is used.

The dhcp keyword in the command signifies that the primary number is obtained via DHCP and the Cisco IOS SIP TDM gateway, Cisco UBE, or Cisco Unified CME on which the command is enabled uses this number to register or unregister the received primary number.

It is mandatory to specify the encryption type for the password. If a clear text password (type 0) is configured, it is encrypted as type 6 before saving it to the running configuration.

If you specify the encryption type as 6 or 7, the entered password is checked against a valid type 6 or 7 password format and saved as type 6 or 7 respectively.

Type-6 passwords are encrypted using AES cipher and a user-defined primary key. These passwords are comparatively more secure. The primary key is never displayed in the configuration. Without the knowledge of the primary key, type 6 passwords are unusable. If the primary key is modified, the password that is saved as type 6 is re-encrypted with the new primary key. If the primary key configuration is removed, the type 6 passwords cannot be decrypted, which may result in the authentication failure for calls and registrations.

When backing up a configuration or migrating the configuration to another device, the primary key is not dumped. Hence the primary key must be configured again manually.

To configure an encrypted preshared key, see Configuring an Encrypted Preshared Key.

Warning: Command has been added to the configuration using a type 7 password. However, type 7 passwords will soon be deprecated. Migrate to a supported password type 6.

In YANG, you cannot configure the same username across two different realms.

To specify the preference for a SRTP cipher-suite that will be offered by Cisco Unified Border Element (CUBE) in the SDP in offer and answer, use the crypto command in voice class configuration mode. To disable this functionality, use the no form of this command.

crypto preference cipher-suite

no crypto preference cipher-suite

Command Default: If this command is not configured, the default behavior is to offer the srtp-cipher suites in the following preference order:

• AEAD_AES_256_GCM

• AEAD_AES_128_GCM

• AES_CM_128_HMAC_SHA1_80

• AES_CM_128_HMAC_SHA1_32

Command Mode: voice class srtp-crypto (config-class)

Usage Guidelines: If you change the preference of an already configured cipher-suite, the preference is overwritten.

To generate Rivest, Shamir, and Adelman (RSA) key pairs, use the crypto key generate rsa command in global configuration mode.

crypto key generate rsa [ { general-keys | usage-keys | signature | encryption } ] [ label key-label ] [ exportable ] [ modulus modulus-size ] [ storage devicename : ] [ redundancy on devicename : ]

Command Default: RSA key pairs do not exist.

Command Mode: Global configuration (config)

Usage Guidelines: Use the crypto key generate rsa command to generate RSA key pairs for your Cisco device (such as a router).

RSA keys are generated in pairs--one public RSA key and one private RSA key.

If your router already has RSA keys when you issue this command, you will be warned and prompted to replace the existing keys with new keys.

The crypto key generate rsa command is not saved in the router configuration; however, the RSA keys generated by this command are saved in the private configuration in NVRAM (which is never displayed to the user or backed up to another device) the next time the configuration is written to NVRAM.

• Special-Usage Keys: If you generate special-usage keys, two pairs of RSA keys will be generated. One pair will be used with any Internet Key Exchange (IKE) policy that specifies RSA signatures as the authentication method, and the other pair will be used with any IKE policy that specifies RSA encrypted keys as the authentication method.

  A CA is used only with IKE policies specifying RSA signatures, not with IKE policies specifying RSA-encrypted nonces. (However, you could specify more than one IKE policy and have RSA signatures specified in one policy and RSA-encrypted nonces in another policy.)

  If you plan to have both types of RSA authentication methods in your IKE policies, you may prefer to generate special-usage keys. With special-usage keys, each key is not unnecessarily exposed. (Without special-usage keys, one key is used for both authentication methods, increasing the exposure of that key).

• General-Purpose Keys: If you generate general-purpose keys, only one pair of RSA keys will be generated. This pair will be used with IKE policies specifying either RSA signatures or RSA encrypted keys. Therefore, a general-purpose key pair might get used more frequently than a special-usage key pair.

• Named Key Pairs: If you generate a named key pair using the key-label argument, you must also specify the usage-keys keyword or the general-keys keyword. Named key pairs allow you to have multiple RSA key pairs, enabling the Cisco IOS software to maintain a different key pair for each identity certificate.

• Modulus Length: When you generate RSA keys, you will be prompted to enter a modulus length. The longer the modulus, the stronger the security. However, a longer modules takes longer to generate (see the table below for sample times) and takes longer to use.

  Table 2. Sample Times by Modulus Length to Generate RSA Keys

  Router	360 bits	512 bits	1024 bits	2048 bits (maximum)
  Cisco 2500	11 seconds	20 seconds	4 minutes, 38 seconds	More than 1 hour
  Cisco 4700	Less than 1 second	1 second	4 seconds	50 seconds

  Cisco IOS software does not support a modulus greater than 4096 bits. A length of less than 512 bits is normally not recommended. In certain situations, the shorter modulus may not function properly with IKE, so we recommend using a minimum modulus of 2048 bits.

  Additional limitations may apply when RSA keys are generated by cryptographic hardware. For example, when RSA keys are generated by the Cisco VPN Services Port Adapter (VSPA), the RSA key modulus must be a minimum of 384 bits and must be a multiple of 64.

• Specifying a Storage Location for RSA Keys: When you issue the crypto key generate rsa command with the storage devicename : keyword and argument, the RSA keys will be stored on the specified device. This location will supersede any crypto key storage command settings.

• Specifying a Device for RSA Key Generation: You may specify the device where RSA keys are generated. Devices supported include NVRAM, local disks, and USB tokens. If your router has a USB token configured and available, the USB token can be used as cryptographic device in addition to a storage device. Using a USB token as a cryptographic device allows RSA operations such as key generation, signing, and authentication of credentials to be performed on the token. The private key never leaves the USB token and is not exportable. The public key is exportable.

  RSA keys may be generated on a configured and available USB token, by the use of the on devicename : keyword and argument. Keys that reside on a USB token are saved to persistent token storage when they are generated. The number of keys that can be generated on a USB token is limited by the space available. If you attempt to generate keys on a USB token and it is full you will receive the following message:

  % Error in generating keys:no available resources 

  Key deletion will remove the keys stored on the token from persistent storage immediately. (Keys that do not reside on a token are saved to or deleted from nontoken storage locations when the copy or similar command is issued).

• Specifying RSA Key Redundancy Generation on a Device: You can specify redundancy for existing keys only if they are exportable.

To authenticate the certification authority (CA) (by getting the certificate of the CA), use the crypto pki authenticate command in global configuration mode.

crypto pki authenticate name

Command Default: No default behavior or values.

Command Mode: Global configuration (config)

Usage Guidelines: This command is required when you initially configure CA support at your router.

This command authenticates the CA to your router by obtaining the self-signed certificate of the CA that contains the public key of the CA. Because the CA signs its own certificate, you should manually authenticate the public key of the CA by contacting the CA administrator when you enter this command.

If you are using Router Advertisements (RA) mode (using the enrollment command) when you issue the crypto pki authenticate command, then registration authority signing and encryption certificates will be returned from the CA and the CA certificate.

This command is not saved to the router configuration. However. the public keys embedded in the received CA (and RA) certificates are saved to the configuration as part of the Rivest, Shamir, and Adelman (RSA) public key record (called the “RSA public key chain”).

If the CA does not respond by a timeout period after this command is issued, the terminal control will be returned so that it remains available. If this happens, you must reenter the command. Cisco IOS software will not recognize CA certificate expiration dates set for beyond the year 2049. If the validity period of the CA certificate is set to expire after the year 2049, the following error message will be displayed when authentication with the CA server is attempted: error retrieving certificate :incomplete chain If you receive an error message similar to this one, check the expiration date of your CA certificate. If the expiration date of your CA certificate is set after the year 2049, you must reduce the expiration date by a year or more.

To import a certificate manually via TFTP or as a cut-and-paste at the terminal, use the crypto pki import command in global configuration mode.

crypto pki import name certificate

Command Default: No default behavior or values

Command Mode: Global configuration (config)

Usage Guidelines: You must enter the crypto pki 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.)

To declare the trustpoint that your router should use, use the crypto pki trustpoint command in global configuration mode. To delete all identity information and certificates associated with the trustpoint, use the no form of this command.

crypto pki trustpoint name redundancy

no crypto pki trustpoint name redundancy

Command Default: Your router does not recognize any trustpoints until you declare a trustpoint using this command. Your router uses unique identifiers during communication with Online Certificate Status Protocol (OCSP) servers, as configured in your network.

Command Mode: Global configuration (config)

Usage Guidelines:

Declaring Trustpoints

Use the crypto pki trustpoint command to declare a trustpoint, which can be a self-signed root certificate authority (CA) or a subordinate CA. Issuing the crypto pki trustpoint command puts you in ca-trustpoint configuration mode.

You can specify characteristics for the trustpoint using the following subcommands:

• crl —Queries the certificate revocation list (CRL) to ensure that the certificate of the peer has not been revoked.

• default (ca-trustpoint) —Resets the value of ca-trustpoint configuration mode subcommands to their defaults.

• enrollment —Specifies enrollment parameters (optional).

• enrollment http-proxy —Accesses the CA by HTTP through the proxy server.

• enrollment selfsigned —Specifies self-signed enrollment (optional).

• match certificate —Associates a certificate-based access control list (ACL) defined with the crypto ca certificate map command.

• ocsp disable-nonce —Specifies that your router will not send unique identifiers, or nonces, during OCSP communications.

• primary —Assigns a specified trustpoint as the primary trustpoint of the router.

• root —Defines the TFTP to get the CA certificate and specifies both a name for the server and a name for the file that will store the CA certificate.

Specifying Use of Unique Identifiers

When using OCSP as your revocation method, unique identifiers, or nonces, are sent by default during peer communications with the OCSP server. The use of unique identifiers during OCSP server communications enables more secure and reliable communications. However, not all OCSP servers support the use of unique dentures, see your OCSP manual for more information. To disable the use of unique identifiers during OCSP communications, use the ocsp disable-nonce subcommand.

To manually import (download) the certification authority (CA) certificate bundle into the public key infrastructure (PKI) trustpool to update or replace the existing CA bundle, use the crypto pki trustpool import command in global configuration mode. To remove any of the configured parameters, use the no form of this command.

crypto pki trustpool import clean [ terminal | url url ]

no crypto pki trustpool import clean [ terminal | url url ]

Command Default: The PKI trustpool feature is enabled. The router uses the built-in CA certificate bundle in the PKI trustpool, which is updated automatically from Cisco.

Command Mode: Global configuration (config)

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

PKI trustpool certificates are automatically updated from Cisco. When the PKI trustpool certificates are not current, use the crypto pki trustpool import command to update them from another location.

The url argument specifies or changes the URL file system of the CA. The table below lists the available URL file systems.

Table 3. URL File Systems

File System	Description
archive:	Imports from the archive file system.
cns:	Imports from the Cluster Namespace (CNS) file system.
disk0:	Imports from the disc0 file system.
disk1:	Imports from the disc1 file system.
ftp:	Imports from the FTP file system.
http:	Imports from the HTTP file system. The URL must be in the following formats: http://CAname:80, where CAname is the Domain Name System (DNS) http://ipv4-address:80. For example: http://10.10.10.1:80. http://[ipv6-address]:80. For example: http://[2001:DB8:1:1::1]:80. The IPv6 address is in hexadecimal notation and must be enclosed in brackets in the URL.
https:	Imports from the HTTPS file system. The URL must use the same formats as the HTTP: file system formats.
null:	Imports from the null file system.
nvram:	Imports from NVRAM file system.
pram:	Imports from Parameter Random-access Memory (PRAM) file system.
rcp:	Imports from the remote copy protocol (rcp) file system.
scp:	Imports from the secure copy protocol (scp) file system.
snmp:	Imports from the Simple Network Management Protocol (SNMP).
system:	Imports from the system file system.
tar:	Imports from the UNIX tar file system.
tftp:	Imports from the TFTP file system.   The URL must be in the from: tftp://CAname/filespecification.
tmpsys:	Imports from the Cisco IOS tmpsys file system.
unix:	Imports from the UNIX file system.
xmodem:	Imports from the xmodem simple file transfer protocol system.
ymodem:	Imports from the ymodem simple file transfer protocol system.

To identify the trustpoint trustpoint-name keyword and argument used during the Transport Layer Security (TLS) handshake that corresponds to the remote device address, use the crypto signaling command in SIP user agent (UA) configuration mode. To reset to the default trustpoint string, use the no form of this command.

crypto signaling { default | remote-addr ip-address subnet-mask } [ tls-profile tag | trustpoint trustpoint-name ] [ cn-san-validation server ] [ client-vtp trustpoint-name ] [ ecdsa-cipher | curve-size 384 | strict-cipher ]

no crypto signaling { default | remote-addr ip-address subnet-mask } [ tls-profile tag | trustpoint trustpoint-name ] [ cn-san-validation server ] [ client-vtp trustpoint-name ] [ ecdsa-cipher | curve-size 384 | strict-cipher ]

Command Default: The crypto signaling command is disabled.

Command Mode: SIP UA configuration (sip-ua)

Usage Guidelines: The trustpoint trustpoint-name keyword and argument refers to the CUBE certificate generated as part of the enrollment process using Cisco IOS PKI commands.

When a single certificate is configured, it is used by all the remote devices and is configured by the default keyword.

When multiple certificates are used, they may be associated with remote services using the remote-addr argument for each trustpoint. The remote-addr and default arguments may be used together to cover all services as required.

The default cipher suite in this case is the following set that is supported by the SSL layer on CUBE: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA1 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

The keyword cn-san-validate server enables server identity validation through the CN and SAN fields in the certificate when establishing client-side SIP/TLS connections. Validation of the CN and SAN fields of the server certificate ensures that the server-side domain is a valid entity. When creating a secure connection with a SIP server, CUBE validates the configured session target domain name against the CN/SAN fields in the server’s certificate before establishing a TLS session. Once you configure cn-san-validate server, validation of the server identity happens for every new TLS connection.

The tls-profile option associates the TLS policy configurations made through the associated voice class tls-profile configuration. In addition to the TLS policy options available directly with the crypto signaling command, a tls-profile also includes the sni send option.

sni send enables Server Name Indication (SNI), a TLS extension that allows a TLS client to indicate the name of the server it is trying to connect to during the initial TLS handshake process. Only the fully qualified DNS hostname of the server is sent in the client hello. SNI does not support IPv4 and IPv6 addresses in the client hello extension. After receiving a "hello" with the server name from the TLS client, the server uses the appropriate certificate in the subsequent TLS handshake process. SNI requires TLS version 1.2.

The TLS policy features will only be available through a voice class tls-profile configuration. The crypto signaling command continues to support previously existing TLS crypto options. You can use either the voice class tls-profile tag or crypto signaling command to configure a trustpoint. We recommend that you use the voice class tls-profile tag command to perform TLS profile configurations.