Cisco Cloud Services Router 1000V Common Criteria

Cisco Cloud Services Router 1000V
Common Criteria Configuration Guide
Version 0.4
5 Janurary 2018
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2017 Cisco Systems, Inc. All rights reserved.
Table of Contents
1
Introduction ............................................................................................................................. 7
Audience ......................................................................................................................... 7
Purpose............................................................................................................................ 7
Document References ..................................................................................................... 7
Supported Hardware and Software ................................................................................. 8
Operational Environment ................................................................................................ 8
Required non-TOE Hardware/ Software/ Firmware ............................................................ 8
Excluded Functionality ................................................................................................... 9
2
Secure Acceptance of the TOE ............................................................................................. 10
3
Secure Installation and Configuration .................................................................................. 13
Initial Setup via Direct Console Connection ................................................................ 13
Options to be chosen during the initial setup of the CSR1000V ........................................ 13
Saving Configuration .................................................................................................... 13
FIPS Mode .................................................................................................................. 14
Administrator Configuration and Credentials ................................................................... 14
Session Termination..................................................................................................... 14
User Lockout ............................................................................................................. 15
4
Secure Management .............................................................................................................. 15
User Roles ..................................................................................................................... 15
Passwords ...................................................................................................................... 16
Virtual Private Networks (VPN) ................................................................................... 17
Generate a key pair ................................................................................................... 18
X.509 Certificates ..................................................................................................... 18
IKEv1 .......................................................................................................................... 21
IKEv2 .......................................................................................................................... 22
Configure IPsec ........................................................................................................... 24
NAT Traversal ............................................................................................................. 29
Storing Certificates to a Local Storage Location .............................................................. 29
Manually Overriding the OCSP Server Setting in a Certificate .......................................... 29
Configuring Certificate Chain Validation ......................................................................... 30
2
IPsec Session Interruption/Recovery ......................................................................... 30
Product Updates ............................................................................................................ 30
Clock Management ....................................................................................................... 31
Configure Reference Identifier ..................................................................................... 31
Identification and Authentication ................................................................................. 32
5
Security Relevant Events ...................................................................................................... 33
Deleting Audit Records................................................................................................. 49
6
Network Protocols and Cryptographic Settings .................................................................... 49
Remote Administration Protocols ................................................................................. 49
Steps to configure SSH on router: ................................................................................. 49
Steps to configure IPsec peer to peer on router: ............................................................. 50
Logging Configuration.................................................................................................. 53
Logging Protection........................................................................................................ 54
Syslog Server Running on an IPsec Endpoint ................................................................. 54
Syslog Server Adjacent to an IPsec Peer ....................................................................... 55
Base Firewall Rule set Configuration ........................................................................... 56
Unevaluated Features .................................................................................................... 59
7
Modes of Operation .............................................................................................................. 60
8
Security Measures for the Operational Environment............................................................ 61
9
Related Documentation ......................................................................................................... 61
World Wide Web .......................................................................................................... 62
Ordering Documentation .............................................................................................. 62
Documentation Feedback.............................................................................................. 62
10
Obtaining Technical Assistance ............................................................................................ 63
3
List of Tables
Table 1 Acronyms ........................................................................................................................... 5
Table 2 Cisco Documentation and CI List ..................................................................................... 7
Table 3 Operational Environment Components ............................................................................. 8
Table 4 Excluded Functionality ..................................................................................................... 9
Table 5: Auditable Events ............................................................................................................. 34
Table 6 Auditable Administrative Events .................................................................................... 41
Table 7 Operational Environment Security Measures .................................................................. 61
4
List of Acronyms
The following acronyms and abbreviations are used in this document:
Table 1 Acronyms
Acronyms /
Abbreviations
AAA
AES
CC
CEM
CM
DRBG
EAL
EC-DH
ECDSA
ESP
FIPS
GCM
HMAC
HTTPS
IKE
IP
IPsec
IT
PP
RFC
SHS
SPD
ST
TCP
TOE
TSC
TSF
TSP
UDP
VPN
Definition
Administration, Authorization, and Accounting
Advanced Encryption Standard
Common Criteria for Information Technology Security Evaluation
Common Evaluation Methodology for Information Technology Security
Configuration Management
Deterministic Random Bit Generator
Evaluation Assurance Level
Elliptic Curve-Diffie-Hellman
Elliptic Curve Digital Signature Algorithm
Encapsulating Security Payload
Federal Information Processing Standards
Galois Counter Mode
Hash Message Authentication Code
Hyper-Text Transport Protocol Secure
Internet Key Exchange
Internet Protocol
Internet Protocol Security
Information Technology
Protection Profile
Request For Comment
Secure Hash Standard
Security Policy Database
Security Target
Transport Control Protocol
Target of Evaluation
TSF Scope of Control
TOE Security Function
TOE Security Policy
User datagram protocol
Virtual Private Network
5
DOCUMENT INTRODUCTION
Prepared By:
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
DOCUMENT INTRODUCTION
This document provides supporting evidence for an evaluation of a specific Target of Evaluation
(TOE), the Cloud Services Router 1000V with Cisco IOS XE Software Release 16.3.2 (CSR).
This Operational User Guidance with Preparative Procedures addresses the administration of the
TOE software and describes how to install, configure, and maintain the TOE in the Common
Criteria evaluated configuration. Administrators of the TOE will be referred to as
administrators, authorized administrators, TOE administrators, semi-privileged administrators,
and privileged administrators in this document. All administrative actions that are relevant to the
Common Criteria (CC) Evaluation and claimed Protection Profile(s) are described within this
document. This document will include pointers to the official Cisco documentation in order to
aid the administrator in easily identifying the CC relevant administrative commands, including
subcommands, scripts (if relevant), and configuration files, that are related to the configuration
(including enabling or disabling) of the mechanisms implemented in CSR that are necessary to
enforce the requirements specified in the claimed PP(s).
6
1 Introduction
This Operational User Guidance with Preparative Procedures documents the administration of
the Cloud Services Router 1000V with Cisco IOS XE Software Release 16.3.2 (CSR), the TOE,
as it was certified under Common Criteria. The Cloud Services Router 1000V with Cisco IOS
XE Software Release 16.3.2(CSR) may be referenced below as CSR, TOE, or simply router.
Audience
This document is written for administrators configuring the TOE. This document assumes that
you are familiar with the basic concepts and terminologies used in internetworking, and
understand your network topology and the protocols that the devices in your network can use,
that you are a trusted individual, and that you are trained to use the operating systems on which
you are running your network.
Purpose
This document is the Operational User Guidance with Preparative Procedures for the Common
Criteria evaluation. It was written to highlight the specific TOE configuration and administrator
functions and interfaces that are necessary to configure and maintain the TOE in the evaluated
configuration. This document is not meant to detail specific actions performed by the
administrator but rather is a road map for identifying the appropriate locations within Cisco
documentation to get the specific details for configuring and maintaining CSR1000V operations.
Document References
This section lists the Cisco Systems documentation that is also the Common Criteria
Configuration Item (CI) List. The documents used are shown below in Table 2. Throughout this
document, the guides will be referred to by the “#”, such as [1].
Table 2 Cisco Documentation and CI List
#
Title
Link
[1]
Cisco CSR 1000V Series Cloud
Services Router Software
Configuration Guide
http://www.cisco.com/c/en/us/td/docs/routers/csr1000/software/configu
ration/csr1000Vswcfg.html
[2]
Cisco CSR 1000V Series Cloud
Services Router Release Notes
http://www.cisco.com/c/en/us/td/docs/routers/csr1000/release/notes/xe16/csr1000v-rel-notes-xe-16-3.html
[3]
Configuration Fundamentals
Configuration Guide
http://www.cisco.com/c/en/us/td/docs/iosxml/ios/fundamentals/configuration/xe-16/fundamentals-xe-16book.html
[4]
Loading and Managing System
Images Configuration Guide
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sys-imagemgmt/configuration/xe-16/sysimgmgmt-xe-16-book.html
[7]
Public Key Infrastructure
Configuration Guide
http://www.cisco.com/c/en/us/td/docs/iosxml/ios/sec_conn_pki/configuration/xe-16/sec-pki-xe-16-book.html
[8]
Easy VPN Configuration Guide
http://www.cisco.com/c/en/us/td/docs/iosxml/ios/sec_conn_esyvpn/configuration/xe-16/sec-easy-vpn-xe-16book.html
7
#
Title
Link
[9]
FlexVPN and Internet Key
Exchange Version 2
Configuration Guide
http://www.cisco.com/c/en/us/td/docs/iosxml/ios/sec_conn_ike2vpn/configuration/xe-16/sec-flex-vpn-xe-16book.html
[10]
Internet Key Exchange for IPsec
VPNs Configuration Guide
http://www.cisco.com/c/en/us/td/docs/iosxml/ios/sec_conn_ikevpn/configuration/xe-16/sec-ike-for-ipsec-vpnsxe-16-book.html
[11]
Cisco IOS Security Command
Reference: Commands A to C
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1cr-book.html
[12]
Cisco IOS Security Command
Reference: Commands D to L
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/d1/sec-d1cr-book.html
[13]
Cisco IOS Security Command
Reference: Commands M to R
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/m1/sec-m1cr-book.html
[14]
Cisco IOS Security Command
Reference: Commands S to Z
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/s1/sec-s1cr-book.html
Supported Hardware and Software
Only the hardware and software listed in section 1.5 of the Security Target (ST) is compliant
with the Common Criteria evaluation. Using any software version other than the evaluated
software listed in the ST will invalidate the secure configuration.
Operational Environment
Required non-TOE Hardware/ Software/ Firmware
The TOE supports (in some cases optionally) the following hardware, software, and firmware in
its environment when the TOE is configured in its evaluated configuration:
Table 3 Operational Environment Components
Component
RADIUS AAA
Server
Mandatory
No
Usage/Purpose Description for TOE performance
This includes any IT environment RADIUS AAA server that provides singleuse authentication mechanisms. This can be any RADIUS AAA server that
provides single-use authentication. The TOE correctly leverages the services
provided by this RADIUS AAA server to provide single-use authentication to
administrators.
Management
Workstation
with SSH client
Yes
This includes any IT Environment Management workstation with a SSH client
installed that is used by the TOE administrator to support TOE administration
through SSH protected channels. Any SSH client that supports SSHv2 may be
used.
Local Console
Yes
This includes any IT Environment Console that is directly connected to the
TOE via the Serial Console Port and is used by the TOE administrator to
support TOE administration.
8
Component
Certification
Authority (CA)
Mandatory
Yes
Usage/Purpose Description for TOE performance
This includes any IT Environment Certification Authority on the TOE
network. This can be used to provide the TOE with a valid certificate during
certificate enrolment.
Remote VPN
Gateway/Peer
Yes
This includes any VPN peer with which the TOE participates in VPN
communications. Remote VPN Endpoints may be any device that supports
IPsec VPN communications.
NTP Server
No
The TOE supports communications with an NTP server in order to
synchronize the date and time on the TOE with the NTP server’s date and
time. A solution must be used that supports secure communications with up
to a 32 character key.
Audit (syslog)
Server
Yes
This includes any syslog server to which the TOE would transmit syslog
messages.
Another
instance of the
TOE
No
Includes “another instance of the TOE” that would be installed in the
evaluated configuration, and likely administered by the same personnel. Used
as a VPN peer.
Excluded Functionality
Table 4 Excluded Functionality
Excluded Functionality
Non-FIPS 140-2 mode of operation on the TOE
Exclusion Rationale
This mode of operation allows cryptographic
operations that are not FIPS-approved.
The excluded functionality in table 4 will be disabled by configuration. The exclusion of this
functionality does not affect compliance to the NDcPP v1.0 and VPNGWEP v2.0.
9
2 Secure Acceptance of the TOE
In order to ensure the correct TOE is received, the TOE should be examined to ensure that that is
has not been tampered with during delivery.
Step 1 Go to the product page for Cisco Routers at
http://www.cisco.com/c/en/us/products/routers/index.html
Step 2 Navigate to the Cisco CSR 1000V Cloud Services Router product page.
Step 3 Click the “Download Software” link
Step 4 Select the Cisco IOS XE release package and click Download Now or Add to Cart.
Follow the instructions for downloading the software. Do not download the REST API Support
file.
The following file types are available in the Cisco CSR 1000V software image package and are
used to install the Cisco CSR 1000V software on the hypervisors.

.OVA - Used for deploying the OVA template on the VM (in TAR format)
Description: Cisco CSR1000V IOS XE UNIVERSAL - CRYPTO OVA
Release: Denali-16.3.2
File Name: csr1000v-universalk9.16.03.02.ova
MD5 Checksum: 0311b809107e1d045e2e0a31ee74f4eb
SHA512 Checksum:
054c354dd63290a05f6958f6574a3065e408f5278b6353196b473d4856bce6a9fd2a6f903cd7c4d5
dd94fab18308558e2361e5083391eaef6a0842da9c5ce33c

.ISO - Used for installing the software image on the VM (requires manually creating the
VM)
Description: Cisco CSR1000V IOS XE Universal - CRYPTO ISO
Release: Denali-16.3.2
File Name: csr1000v-universalk9.16.03.02.iso
MD5 Checksum: 8d1acb8cfdbce04cef67690c82729248
SHA512 Checksum:
3f58d8a364d20aa0cd4f3a9eaa865d6521184444a101a5585dd59cf913779b57d83cd6dcdab0d613
0f5a72f693ca081057cd05a399d835e1807e2512cf641e18
10
Step 5 Install the downloaded software image onto a supported Hypervisor as described under
the "Installing the Cisco CSR 1000V in VMware ESXi Environments" section of [1]:
Step 6 Boot the CSR 1000V as described in the “Booting the Cisco CSR 1000V and Accessing
the Console” section of [1].
The TOE will automatically display the hash verification on boot or by using the reload
command. The successful hash verification message will display on successful verification of
the boot image. If the image was tampered with in any way, an error would display and the
image will not boot. Confirm that the CSR1000V loads the image correctly, completes internal
self-checks and displays the cryptographic export warning on the console.
Once the image is loaded into bootflash, to display information related to software authenticity
for a specific image file, use the verify command. For example:
CSR1000V# verify csr1000v-mono-universalk9.03.16.03.S.155-3.S-std.SPA.pkg
Verifying file integrity of bootflash:csr1000v-mono-universalk9.03.16.03.S.155-3.Sstd.SPA.pkg.......................................................................................................................................
...
Embedded Hash SHA1 : B23B19DF60B5CF03C0DDF38AF21D7D57A677FC3B
Computed Hash SHA1 : B23B19DF60B5CF03C0DDF38AF21D7D57A677FC3B
Starting image verification
Hash Computation: 100%Done!
Computed Hash SHA2: f67b82ada56f5d3425f3481665feff36
a189addef4756fdfc7670b6836ce99fd
61f7db3e65d44c563d49d5bc6a9fcf32
e4d4b04a146cd0d634b831fdf7dea690
Embedded Hash SHA2: f67b82ada56f5d3425f3481665feff36
a189addef4756fdfc7670b6836ce99fd
61f7db3e65d44c563d49d5bc6a9fcf32
e4d4b04a146cd0d634b831fdf7dea690
Digital signature successfully verified in file bootflash:csr1000v-monouniversalk9.03.16.03.S.155-3.S-std.SPA.pkg
Embedded hash verification successful.
If the image is corrupted, then the following will result:
CSR1000V# verify csr1000v-mono-universalk9.03.16.03.S.155-3.S-std.SPA.pkg.BAD.SPA
%Error verifying csr1000v-mono-universalk9.03.16.03.S.155-3.S-std.SPA.pkg.BAD.SPA:
Digital signature is not present
11
CSR1000V#
*Jul 16 19:37:58.339: %DIGISIGN-4-SIGNATURE_NOT_PRESENT: %WARNING: Digital
signature is not found in file csr1000v-mono-universalk9.03.16.03.S.155-3.Sstd.SPA.pkg.BAD.SPA
If the image verification does not complete successfully, contact Cisco Technical Assistance
Center (TAC) https://tools.cisco.com/ServiceRequestTool/create/launch.do.
12
3 Secure Installation and Configuration
Initial Setup via Direct Console Connection
The CSR1000V must be given basic configuration via console connection prior to being
connected to any network.
Before proceeding, the administrator shall be familiar with configuring Cisco devices. Refer to
the “Overview Basic Configuration of a Cisco Networking Device” chapter found in [3]
Options to be chosen during the initial setup of the CSR1000V
When you run the “setup” command, or after initially turning on the router you are free to choose
answers that fit your policies with the exception of the following values:
1. The administrator must create an initial configuration as described in “Using the System
Configuration Dialog to Create an Initial Configuration File” section of Using Setup
Mode to Configure a Cisco Networking Device chapter of [3].
2. The administrator must create an Enable Secret password, as described in step 6 in
“Using the System Configuration Dialog to Create an Initial Configuration File” section
of Using Setup Mode to Configure a Cisco Networking Device chapter of [3]. The
Enable Secret password must adhere to the password complexity requirements. Note that
this setting can be confirmed after “setup” is complete by examining the configuration
file for “enable secret”.
3. The administrator must create an Enable password, as described in step 7 in “Using the
System Configuration Dialog to Create an Initial Configuration File” section of Using
Setup Mode to Configure a Cisco Networking Device chapter of [3]. The Enable
password must adhere to the password complexity requirements. Note that this setting
can be confirmed after “setup” is complete by examining the configuration file for
“enable”.
4. The administrator must create a Virtual Terminal password, as described in step 8 in
“Using the System Configuration Dialog to Create an Initial Configuration File” section
of Using Setup Mode to Configure a Cisco Networking Device chapter of [3]. The
Enable password must adhere to the password complexity requirements. Note that this
setting can be confirmed after “setup” is complete by examining the configuration file for
“vty”.
5. The administrator must select NO (this is the default) when prompted to Configure
SNMP Network Management as described in step 9 in “Using the System Configuration
Dialog to Create an Initial Configuration File” section of Using Setup Mode to Configure
a Cisco Networking Device chapter of [3].
Saving Configuration
IOS-XE uses both a running configuration and a starting configuration. Configuration changes
affect the running configuration, in order to save that configuration the running configuration
(held in memory) must be copied to the startup configuration. This may be achieved by either
using the write memory command or the copy system:running-config nvram:startup-config
command. These commands should be used frequently when making changes to the
configuration of the Router. If the Router reboots and resumes operation when uncommitted
13
changes have been made, these changes will be lost and the Router will revert to the last
configuration saved.
FIPS Mode
The TOE must be run in the FIPS mode of operation. This is done by following the configuration
in this CC Guidance Document. By configuring the TOE to use the specified CC allowed
cryptographic algorithms and key sizes as described in this document, the TOE will be in FIPS
mode.
The self-tests for the cryptographic functions in the TOE are run automatically during power-on
as part of the POST. The same POST self-tests for the cryptographic operations can also be
executed manually at any time by the privileged administrator using the command:
test crypto self-test.
Administrator Configuration and Credentials
The CSR1000V must be configured to use a username and password for each administrator and
one password for the enable command. Ensure all passwords are stored encrypted by using the
following command:
service password-encryption
Configures local AAA authentication:
aaa authentication login default local
aaa authorization exec default local
When creating administrator accounts, all individual accounts are to be set to a privilege level of
one. This is done by using the following commands:
username <name> password <password>
to create a new username and password combination, and
username <name> privilege 1
to set the privilege level of <name> to 1.
Session Termination
Inactivity settings must trigger termination of the administrator session. These settings are
configurable by setting
line vty <first> <last>
exec-timeout <time>
line console
exec-timeout <time>
To save these configuration settings to the startup configuration:
copy run start
14
where first and last are the range of vty lines on the box (i.e. “0 4”), and time is the period of
inactivity after which the session should be terminated. Configuration of these settings is limited
to the privileged administrator (see Section 4.1).
The line console setting is not immediately activated for the current session. The current console
session must be exited. When the user logs back in, the inactivity timer will be activated for the
new session.
User Lockout
User accounts must be configured to l ockout after a specified number of authentication failures
TOE-common-criteria(config)# aaa local authentication attempts max-fail [number of
failures]
where number of failures is the number of consecutive failures that will trigger locking of the
account. Configuration of these settings is limited to the privileged administrator (see Section
4.1).
Related commands:
clear aaa local user fail-attempts
Clears the unsuccessful login
attempts of the user.
clear aaa local user lockout
username [username]
Unlocks the locked-out user.
show aaa local user lockout
Displays a list of all locked-out
users.
Note: this lockout only applies to privilege 14 users and below.
Note: this applies to consecutive failures, and is not affected by the SSH or Telnet session
disconnections after their default number of failures. In other words, if this lockout command is
set to 5 failures, and SSH disconnects after 3 failed attempts, if the user attempts another SSH
session and enters the wrong credentials two additional times, the account will lock.
4 Secure Management
User Roles
The CSR1000V has both privileged and semi-privileged administrator roles as well as nonadministrative access. Non-administrative access is granted to authenticated neighbor routers for
the ability to receive updated routing tables per the information flow rules. There is no other
access or functions associated with non-administrative access. These privileged and semiprivileged roles are configured in the Access Control and Session Termination section above.
The TOE also allows for customization of other levels. Privileged access is defined by any
privilege level entering an ‘enable secret 5’ after their individual login. Note: The command
‘enable secret’ is a replacement for the ‘enable password’ command since the ‘enable secret’
creates the password and stores it in encrypted. Privilege levels are number 0-15 that specifies
the various levels for the user. The privilege levels are not necessarily hierarchical. Privilege
15
level 15 has access to all commands on the TOE. Privilege levels 0 and 1 are defined by default,
while levels 2-14 are undefined by default. Levels 0-14 can be set to include any of the
commands available to the level 15 administrator, and are considered the semi-privileged
administrator for purposes of this evaluation. The privilege level determines the functions the
user can perform; hence the authorized administrator with the appropriate privileges.
To establish a username-based authentication system, use the username command in global
configuration mode.
(config)# username name [privilege level]
To remove an established username-based authentication, use the no form of this command.
(config)# no username name
Refer to the IOS Command Reference Guide for available commands and associated roles and
privilege levels.
Passwords
The password complexity is not enforced by the router by default, and must be administratively
set in the configuration. To prevent administrators from choosing insecure passwords, each
password must be:
1. At least 15 characters long. Use the following command to set the minimum length to 15
or greater.
TOE-common-criteria(config)#security passwords min-length length
Example: (config)# security passwords min-length 15
Note: Details for the security passwords min-length command can be found in Cisco
IOS Security Command Reference: Commands S to Z [14].
2. Composed of any combination of characters that includes characters for at least 3 of these
four character sets: upper case letters, lower case letters, numerals, and the following
special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”. Configure the router
to enforce that complexity requirement by using enabling “aaa password restriction”.
Example: (config)# aaa password restriction
Enabling aaa password restriction will also enforce the following restrictions:
1. The new password cannot have any character repeated more than three times
consecutively.
2. The new password cannot be the same as the associated username.
3. The password obtained by capitalization of the username or username reversed is not
accepted.
4. The new password cannot be “cisco”, “ocsic”, or any variant obtained by changing the
16
capitalization of letters therein, or by substituting “1”, “|”, or “!” for i, or by substituting “0” for
“o”, or substituting “$” for “s”.
Note: The aaa password restriction command can only be used after the aaa new-model
command is configured. Cisco IOS Security Command Reference: Commands A to C [11].
The following configuration steps are optional, but recommended for good password complexity.
The below items are recommended but are not enforced by the TOE:
1. Does not contain more than three sequential characters, such as abcd
2. Does not contain dictionary words
3. Does not contain common proper names
Administrative passwords, including any “enable” password that may be set for any privilege
level, must be stored in non-plaintext form. To have passwords stored as a SHA-256 hash, use
the “service password-encryption” command in config mode.
(config)#service password-encryption
Once that service has been enabled, passwords can be entered in plaintext, or has SHA-256 hash
values, and will be stored as SHA-256 hash values in the configuration file when using the
“username” command.
(config)#username name {password password | password encryption-type encryptedpassword}
To have IKE preshared keys stored in encrypted form, use the password encryption aes
command to enable the functionality and the key config-key password-encrypt command to set
the master password to be used to encrypt the preshared keys. The preshared keys will be stored
encrypted with symmetric cipher Advanced Encryption Standard [AES].
(config)# password encryption aes
(config)# key config-key password-encryption [text]
Note: Details for the password encryption aes command can be found in Cisco IOS Security
Command Reference: Commands M to R [13].
Virtual Private Networks (VPN)
The TOE allows all privileged administrators to configure Internet Key Exchange (IKE) and
IPsec policies in order for the TOE to communicate to a remote VPN Gateway.
IPsec provides the following network security services:

Data confidentiality--The IPsec sender can encrypt packets before transmitting them
across a network.

Data integrity--The IPsec receiver can authenticate packets sent by the IPsec sender to
ensure that the data has not been altered during transmission.

Data origin authentication--The IPsec receiver can authenticate the source of the sent
IPsec packets. This service is dependent upon the data integrity service.
17

Anti-replay--The IPsec receiver can detect and reject replayed packets.
IPsec provides secure tunnels between two peers, such as two routers. The privileged
administrator defines which packets are considered sensitive and should be sent through these
secure tunnels and specifies the parameters that should be used to protect these sensitive packets
by specifying the characteristics of these tunnels. When the IPsec peer recognizes a sensitive
packet, the peer sets up the appropriate secure tunnel and sends the packet through the tunnel to
the remote peer.
More accurately, these tunnels are sets of security associations (SAs) that are established
between two IPsec peers. The SAs define the protocols and algorithms to be applied to sensitive
packets and specify the keying material to be used by the two peers. SAs are unidirectional and
are established per security protocol (AH or ESP).
Generate a key pair
RSA and ECDSA keys are generated in pairs—one public key and one private key:
(config)# crypto key generate rsa modulus 2048 | 3072 |
4096 exportable
- or –
(config)# crypto key generate ec keysize 256 | 384
exportable
The 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.
The Cisco CSR 1000V encrypts some of the disk partitions internal to the VM to provide extra
security around sensitive data that may be stored on the router. For example, information in
NVRAM is encrypted so that it is not visible to administrative entities with access to the physical
hard disk that the Cisco CSR 1000V is stored on.
Note: Only one set of keys can be configured using the crypto key generate command at a time.
Repeating the command overwrites the old keys.
Note: If the configuration is not saved to NVRAM with a “copy run start”, the generated keys
are lost on the next reload of the router.
Note: If the error “% Please define a domain-name first” is received, enter the command ‘ip
domain-name [domain name
X.509 Certificates
The TOE may be configured by the privileged administrators to use X.509v3 certificates to
authenticate IPsec peers. Both RSA and ECDSA certificates are supported.
Creation of these certificates and loading them on the TOE is covered in [7] under the “Public
Key Infrastructure Configuration Guide”. A portion of the TOE configuration for use of these
certificates follows below:
18
Create Trustpoint
In order for a certificate signing request to be generated, a trustpoint must be configured on the
TOE with an enrollment method along with the type revocation check to perform on the peer.
1. Enter configure terminal mode:
# configure terminal
2. Configure the trustpoint: crypto pki trustpoint trustpoint-name
(config)#crypto pki trustpoint CC-test
3. Configure an enrollment method: enrollment [terminal, url url]
(ca-trustpoint)#enrollment terminal pem
4. Configure subject-name settings for the certificate: subject-name
CN=hostname.domain.com,OU=OU-name
(ca-trustpoint)#subject-name CN=csrTOE.cisco.com,OU=TAC
5. Set revocation check method: revocation-check crl or ocsp
This will set up the certificate revocation mechanism--CRLs or OCSP--that is to be used
to ensure that the certificate of a peer has not been revoked.
If the TOE is unable to obtain a CRL or if the OCSP server returns an error, the TOE will
reject the peer’s certificate.
When using OCSP, nonces, unique identifiers for OCSP requests, are sent by default
during peer communications with a OCSP server. The use of nonces offers a more secure
and reliable communication channel between the peer and OCSP server. If the OCSP
server does not support nonces, an authorized administrator may disable the sending of
nonces.
(ca-trustpoint)#revocation-check crl
- or –
(ca-trustpoint)#revocation-check ocsp
Create a Certificate Signing Request for the TOE
The certificate signing request for the TOE will be created using the RSA or ECDSA key pair
and the domain name configured in Section 4.3.1 above.
(config)#crypto pki enroll CC-test
19
If the enrollment method was terminal, select yes to Display the Certificate Request.
Sign the Certificate Request by the CA
Copy the certificate request to the CA server and have the PKI administrator sign it.
Install the CA cert
1. Enter configure terminal mode:
# configure terminal
2. Authenticate the Trustpoint:
(config)# crypto pki authenticate CC-test
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
Install the TOE device certificate
1. (config)# crypto pki import CC-test certificate
% Router Certificate successfully imported
(config)#
Deleting Certificates
If the need arises, certificates that are saved on the router can be deleted. The router saves its
own certificates and the certificate of the CA.
To delete the router's certificate from the router's configuration, the following commands can be
used in global configuration mode:
Router# show crypto ca certificates [Displays the certificates stored on router]
Router(config)# crypto ca certificate chain name [Enters certificate chain configuration mode]
Router(config-cert-cha)# no certificate certificate-serial-number [deletes the certificate]
To delete the CA's certificate, the entire CA identity must be removed, which also removes all
certificates associated with the CA—router's certificate and the CA certificate. To remove a CA
identity, the following command in global configuration mode can be used:
Router(config)# no crypto ca identity name [Deletes all identity information and certificates
associated with the CA]
20
IKEv1
The TOE evaluated configuration allows IPsec VPN connections to a peer using either IKEv1 or
IKE v2. This section discusses TOE configuration for IKEv1.
An Internet Key Exchange version 1 (IKEv1) policy set represents a certain combination of
security protocols, algorithms type of IKE authentication, DH Group, SA lifetime, and preshared key (if configured)..
The following settings must be set in configuring the IPSec with IKEv1 functionality for the
TOE:
# conf t
(config)#crypto isakmp policy 1
(config-isakmp)# hash sha
(config-isakmp)# encryption {aes | aes 256}
The above configures IPSec IKEv1 to use AES-CBC-128 for payload encryption. AES-CBC-256
can be selected with ‘encryption aes 256’.
Note: the authorized administrator must ensure that the keysize for this setting is greater than or
equal to the keysize selected for ESP in Section 4.3.5.1 below. If AES 128 is selected here, then
the highest keysize that can be selected on the TOE for ESP is AES 128 (either CBC or GCM).
Note: Both confidentiality and integrity are configured with the hash sha and encryption aes
commands respectively. As a result, confidentiality-only mode is disabled.
The evaluated configuration allows authentication of the peer using pre-shared key or
certificates. To configure IKE to authenticate the peer using a pre-shared key:
(config-isakmp)# authentication pre-share
To configure IKE to authenticate using X.509 v3 certificates:
(config-isakmp)# authentication rsa-sig
The group command selects DH Group 14 (2048-bit MODP) for IKE, but 19 (256-bit Random
ECP), 24 (2048-bit MODP with 256-bit POS), 20 (384-bit Random ECP), 15 (3072 bit MODP),
and 16 (4096-bit MODP) are also allowed and supported.
(config-isakmp)# group 14
The default lifetime time value for Phase 1 SAs is 24 hours (86400 seconds), but this setting can
be changed using the command above with different values:
(config-isakmp)# lifetime 86400
21
Main mode is the default mode and the crypto isakmp aggressive-mode disable ensures all
IKEv1 Phase 1 exchanges will be handled in the default main mode.
(config-isakmp)# crypto isakmp aggressive-mode disable
(config-isakmp)#exit
If authentication of the peer was configured for pre-shared key, configure the pre-shared key
value:
(config)# crypto isakmp key cisco123!cisco123!CISC address
[ip address]
Note: Pre-shared keys on the TOE must be at least 22 characters in length and
can be composed of any combination of upper and lower case letters, numbers,
and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”,
“(“, and “)”).
The TOE supports pre-shared keys up to 127 characters in length. While longer keys increase
the difficulty of brute-force attacks, longer keys increase processing time.
Additional information regarding configuration of IKEv1 can be found in IKEv1 Transform Sets
section of [8].
IKEv2
The following steps configure the TOE to use IKEv2:
o
o
o
o
Configuring the IKEv2 Proposal
Configuring the IKEv2 Policy
Configuring the IKEv2 Keyring
Configuring the IKEv2 Profile
Additional information on configuration of IKEv2 can be found in the “Internet Key Exchange
Version 2 CLI Constructs” of [9]. A portion is provided below:
Configuring the IKEv2 Proposal
An IKEv2 proposal is regarded as complete only when it has at least an encryption algorithm, an
integrity algorithm, and a Diffie-Hellman (DH) group configured. If no proposal is configured
and attached to an IKEv2 policy, then the default proposal is used in the negotiation, and it
contains selections that are not valid for the TOE. Thus the following settings must be set in
configuring the IPSec with IKEv2 functionality for the TOE:
# conf t
(config)#crypto ikev2 proposal sample
(config-ikev2-proposal)# integrity sha1
(config-ikev2-proposal)# encryption aes-cbc-128
22
This configures IPSec IKEv2 to use AES-CBC-128 for payload encryption. AESCBC-256 can be selected with ‘encryption aes-cbc-256’.
Note: the authorized administrator must ensure that the keysize for this setting is
greater than or equal to the keysize selected for ESP in Section 4.6.2 below. If
AES 128 is selected here, then the highest keysize that can be selected on the TOE
for ESP is AES 128 (either CBC or GCM).
Note: Both confidentiality and integrity are configured with the hash sha and
encryption aes commands respectively. As a result, confidentiality-only mode is
disabled.
(config-ikev2-proposal)# group 14
This selects DH Group 14 (2048-bit MODP) for IKE, but 19 (256-bit Random
ECP), 24 (2048-bit MODP with 256-bit POS), 20 (384-bit Random ECP), 15
(3072 bit MODP), and 16 (4096-bit MODP) are also allowed and supported.
Configuring the IKEv2 Policy
Perform these steps to manually create an IKEv2 policy
# conf t
(config)#crypto ikev2 policy policy-1 sample
(config-ikev2-policy)# proposal sample
(config-ikev2-policy)# end
Configuring the IKEv2 Keyring
Perform these steps to configure the IKEv2 keyring if the local or remote authentication method
is a preshared key.
(config)#crypto ikev2 keyring keyring-1
(config-ikev2-keyring)# peer peer1
(config-ikev2-keyring-peer)# address 0.0.0.0 0.0.0.0
(config-ikev2-keyring-peer)# pre-shared-key
cisco123!cisco123!CISC
This section creates a keyring to hold the pre-shared keys referenced in the steps
above. In IKEv2 these pre-shared keys are specific to the peer.
Note: Pre-shared keys on the TOE must be at least 22 characters in length and
can be composed of any combination of upper and lower case letters, numbers,
and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”,
“(“, and “)”).
23
The TOE supports pre-shared keys up to 127 characters in length. While longer
keys increase the difficulty of brute-force attacks, longer keys increase processing
time.
HEX keys generated off system can also be input for IKEv2 using the following
instead of the pre-shared-key command above: ‘pre-shared-key hex [hex key]’.
For example: pre-shared-key hex 0x6A6B6C. See ‘Configuring the IKEv2
Keyring’ in [9] for more information on this command.
Configuring the IKEv2 Profile
An IKEv2 profile is a repository of nonnegotiable parameters of the IKE SA (such as
local/remote identities and authentication methods) and the services available to the
authenticated peers that match the profile. An IKEv2 profile must be configured and must be
attached to either a crypto map or an IPSec profile on both the IKEv2 initiator and responder.
(config)#crypto ikev2 profile profile-1
(config-ikev2-profile)#authentication local ecdsa-sig
(config-ikev2-profile)#authentication remote ecdsa-sig
(config-ikev2-profile)#lifetime 86400
(config-ikev2-profile)#pki trustpoint CC-test
(config-ikev2-profile)#end
Additional information on configuration of IKEv2 can be found in the “Internet Key Exchange
Version 2 CLI Constructs” of [9]
Configure IPsec
IPsec Transforms and Lifetimes
Regardless of the IKE version selected, the TOE must be configured with the proper transform
for IPSec ESP encryption and integrity as well as IPSec lifetimes.
During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a
particular data flow.
Privileged administrators can specify multiple transform sets and then specify one or more of
these transform sets in a crypto map entry. The transform set defined in the crypto map entry is
used in the IPsec SA negotiation to protect the data flows specified by that crypto map entry's
access list.
During IPsec security association negotiations with IKE, peers search for a transform set that is
the same at both peers. When such a transform set is found, it is selected and applied to the
protected traffic as part of both peers' IPsec SAs. (With manually established SAs, there is no
negotiation with the peer, so both sides must specify the same transform set.)
24
Note: If a transform set definition is changed during operation that the change is not applied to
existing security associations, but is used in subsequent negotiations to establish new SAs. If you
want the new settings to take effect sooner, you can clear all or part of the SA database by using
the clear crypto sa command
(config)# crypto ipsec transform-set example esp-aes 128
esp-sha-hmac
Note that this configures IPSec ESP to use HMAC-SHA-1 and AES-CBC-128.
To change this to the other allowed algorithms the following options can replace
‘esp-aes 128’ in the command above:
Encryption Algorithm
Command
AES-CBC-256
esp-aes 256
AES-GCM-128
esp-gcm 128
AES-GCM-256
esp-gcm 256
Note: The size of the key selected here must be less than or equal to the key size
selected for the IKE encryption setting in 4.3.3 and 4.3.4 above. If AES-CBC128 was selected there for use with IKE encryption, then only AES-CBC-128 or
AES-GCM-128 may be selected here.
(config-crypto)#mode tunnel
This configures tunnel mode for IPsec. Tunnel is the default, but by explicitly
specifying tunnel mode, the router will request tunnel mode and will accept only
tunnel mode.
-- OR -(config-crypto)#mode transport
The above command will configure the TOE for transport mode. If you use this
command to change the mode, the change will only affect the negotiation of
subsequent IPsec security associations via crypto map entries which specify this
transform set. (If you want the new settings to take effect sooner, you can clear
all or part of the security association database using the clear crypto sa
command.
(config)#crypto ipsec security-association lifetime seconds
28800
The default time value for Phase 2 SAs is 1 hour. There is no configuration
required for this setting since the default is acceptable, however to change the
setting to 8 hours as claimed in the Security Target the crypto ipsec securityassociation lifetime command can be used as specified above.
(config)#crypto ipsec security-association lifetime
kilobytes 100000
25
This configures a lifetime of 100 MB of traffic for Phase 2 SAs. The default
amount for this setting is 2560KB, which is the minimum configurable value for
this command. The maximum configurable value for this command is is 4GB.
Addition information can be found in “How to configure IPsec VPNs” of [8].
IPsec Crypto Map and Access Control List
With IPsec, privileged administrators can define the traffic that needs to be protected between
two IPsec peers by configuring access lists and applying these access lists to interfaces using
crypto map sets. Therefore, traffic may be selected on the basis of the source and destination
address, and optionally the Layer 4 protocol and port. (The access lists used for IPsec are only
used to determine the traffic that needs to be protected by IPsec, not the traffic that should be
blocked or permitted through the interface. Separate access lists define blocking and permitting
at the interface). For example:
# conf t
(config)# access-list 101 permit ip 192.168.3.0 0.0.0.255
10.3.2.0 0.0.0.255
When a packet matches a permit entry in a particular access list, the method of security in the
corresponding crypto map is applied. If the crypto map entry is tagged as ipsec-isakmp, IPsec is
triggered. For example:
(config)#crypto map armadillo 10 ipsec-isakmp
The match address 101 command means to use access list 101 in order to determine which
traffic is relevant. For example:
(config-crypto-map)#match address 101
The traffic matching permit ACL would then flow through the IPsec tunnel and be classified as
“PROTECTED”.
Traffic that does not match a permit crypto map ACL and does not match a non-crypto permit
ACL on the interface would be DISCARDED.
Traffic that does not match a permit ACL in the crypto map, but does match a non-crypto permit
ACL would be allowed to BYPASS the tunnel. For example, a non-crypto permit ACL for icmp
would allow ping traffic to flow unencrypted if a permit crypto map was not configured that
matches the ping traffic.
A crypto map set can contain multiple entries, each with a different access list. The crypto map
entries are searched in a sequence--the router attempts to match the packet to the access list
specified in that entry.
When a packet matches a permit entry in a particular access list, and the corresponding crypto
map entry is tagged as cisco, connections are established, if necessary. If the crypto map entry is
tagged as ipsec-isakmp, IPsec is triggered.
If there is no SA that the IPsec can use to protect this traffic to the peer (VPN Gateway), IPsec
uses IKE to negotiate with the remote peer to set up the necessary IPsec SAs on behalf of the
26
data flow. The negotiation uses information specified in the crypto map entry as well as the data
flow information from the specific access list entry.
Once established, the set of SAs (outbound to the peer) is then applied to the triggering packet
and to subsequent applicable packets as those packets exit the router. "Applicable" packets are
packets that match the same access list criteria that the original packet matched. For example, all
applicable packets could be encrypted before being forwarded to the remote peer. The
corresponding inbound SAs are used when processing the incoming traffic from that peer.
Access lists associated with IPsec crypto map entries also represent the traffic that the router
needs protected by IPsec. Inbound traffic is processed against crypto map entries--if an
unprotected packet matches a permit entry in a particular access list associated with an IPsec
crypto map entry, that packet is dropped because it was not sent as an IPsec-protected packet.
Crypto map entries also include transform sets. A transform set is an acceptable combination of
security protocols, algorithms, and other settings that can be applied to IPsec-protected traffic.
During the IPsec SA negotiation, the peers agree to use a particular transform set when
protecting a particular data flow.
Additional information regarding configuration of IPsec can be found in the [8] under “Crypto
Access Lists” of [9].
This functionality is available to the Privileged Administrator. Configuration of VPN settings is
restricted to the privileged administrator.
Configure Reference Identifier
This section describes configuration of the peer reference identifier which is achieved through a
certificate map.
Certificate maps provide the ability for a certificate to be matched with a given set of criteria.
You can specify which fields within a certificate should be checked and which values those
fields may or may not have. There are six logical tests for comparing the field with the value:
equal, not equal, contains, does not contain, less than, and greater than or equal. ISAKMP and
ikev2 profiles can bind themselves to certificate maps, and the TOE will determine if they are
valid during IKE authentication.
Step1
(config)# crypto pki certificate map
label sequence-number
Starts certificate-map mode
Step2
(ca-certificate-map)# field-name matchcriteria match-value
In ca-certificate-map mode, you specify one or more
certificate fields together with their matching criteria and the
value to match.

field-name—Specifies one of the following caseinsensitive name strings or a date:
–subject-name
–issuer-name
–unstructured-subject-name
–alt-subject-name
–name
27
–valid-start
–expires-on
Note Date field format is dd mm yyyy hh:mm:ss or mm dd
yyyy hh:mm:ss.

match-criteria—Specifies one of the following
logical operators:
–eq—Equal (valid for name and date fields)
–ne—Not equal (valid for name and date fields)
–co—Contains (valid only for name fields)
–nc—Does not contain (valid only for name fields)
–lt —Less than (valid only for date fields)
–ge —Greater than or equal (valid only for date
fields)

match-value—Specifies the name or date to test with
the logical operator assigned by match-criteria.
Step3
(ca-certificate-map)# exit
Exits ca-certificate-map mode.
Step4
For IKEv1:
crypto isakmp profile ikev1-profile1
match certificate label
Associates the certificate-based ACL defined with the crypto
pki certificate map command to the profile.
For IKEv2:
crypto ikev2 profile ikev2-profile1
match certificate label
For example: To create a certificate map for IKEv1 to match four subject-name values of the
peer enter:
# conf t
(config)# crypto pki certificate map cert-map-match-all 99
(ca-certificate-map)# subject-name co cn=CC_PEER
(ca-certificate-map)# subject-name co o=ACME
(ca-certificate-map)# subject-name co ou=North America
(ca-certificate-map)# subject-name co c=US
(ca-certificate-map)#exit
(config)# crypto isakmp profile ike1-profile-match-cert
match certificate cert-map-match-all
For more information refer to the “How to Configure Certificate to ISAKMP Profile Mapping”
section in [10].
28
NAT Traversal
The IPsec NAT Transparency feature provides mandatory support for IKEv2 traffic to travel
through Network Address Translation (NAT). NAT Traversal is a feature that is auto detected.
There are no configuration steps on the TOE. If the VPN device is NAT-T capable, NAT
Traversal is auto detected and auto negotiated. The administrator can refer to this IPsec NAT
Transparency document for additional information.
Storing Certificates to a Local Storage Location
Certificates are stored to NVRAM by default; however, some routers do not have the required
amount of NVRAM to successfully store certificates. All Cisco platforms support NVRAM and
flash local storage. Depending on the platform, an authorized administrator may have other
supported local storage options including bootflash, slot, disk, USB flash, or USB token. During
run time, an authorized administrator can specify what active local storage device will be used to
store certificates. For more detailed information see the "How to Configure PKI Storage" section
within the Storing PKI Credentials chapter of Public Key Infrastructure Configuration Guide
How to Specify a Local Storage Location for Certificates
The summary steps for storing certificates locally to the TOE are as follows:
1. Enter configure terminal mode:
Device# configure terminal
2. Specify the local storage location for certificates: crypto pki certificate storage
location-name
Device(config)# crypto pki certificate storage flash:/certs
3. Exit:
Device(config)# exit
4. Save the changes made:
Device# copy system:running-config nvram:startup-config
5. Display the current setting for the PKI certificate storage location:
Device# show crypto pki certificates storage
The following is sample output from the show crypto pki certificates storage command, which
shows that the certificates are stored in the certs subdirectory of disk0:
Device# show crypto pki certificates storage
Certificates will be stored in disk0:/certs/
This administrator should note that from the point of view of the hypervisor, local certificate
storage refers to a VMware VMFS formatted virtual disk.
Manually Overriding the OCSP Server Setting in a Certificate
Administrators can override the OCSP server setting specified in the Authority Information
Access (AIA) field of the client certificate or set by the issuing the ocsp url command. One or
more OCSP servers may be manually specified, either per client certificate or per group of client
certificates by the match certificate override ocsp command. The match certificate override
ocspcommand overrides the client certificate AIA field or the ocsp urlcommand setting if a client
29
certificate is successfully matched to a certificate map during the revocation check
Configuring Certificate Chain Validation
Perform this task to configure the processing level for the certificate chain path of peer
certificates.
Prerequisites:


The device must be enrolled in your PKI hierarchy.
The appropriate key pair must be associated with the certificate.
1. Enter configure terminal mode:
# configure terminal
2. Set the crypto pki trustpoint name:
(config)# crypto pki trustpoint ca-sub1
3. Configure the level to which a certificate chain is processed on all certificates including
subordinate CA certificates using the chain-validation [{stop | continue} [parenttrustpoint]] command:
(ca-trustpoint)# chain-validation continue ca-sub1
 Use the stop keyword to specify that the certificate is already trusted. This is the
default setting.
 Use the continue keyword to specify that the that the subordinate CA certificate
associated with the trustpoint must be validated.
 The parent-trustpoint argument specifies the name of the parent trustpoint the
certificate must be validated against.
Note: A trustpoint associated with the root CA cannot be configured to be validated to
the next level. The chain-validation command is configured with the continue keyword
for the trust point associated with the root CA, an error message will be displayed and
the chain validation will revert to the default chain-validation command setting.
4. Exit:
(ca-trustpoint)# exit
IPsec Session Interruption/Recovery
If an IPsec session with a VPN Gateway is unexpectedly interrupted, the connection will be
broken. In these cases the IPsec session will need to be reestablished (a new SA set up) once the
peer is back online.
Product Updates
Bug fixes and security patches that occur after certification completion, which will be denoted by
release(s) numbered 16.3.z and higher numbers of z, should be installed, in accordance with
FPT_TUD_EXT.1 from the protection profile and NIAP Policy #22 are considered to keep the
TOE in the evaluated configuration.
TOE software updates are a new image. Verification of authenticity of updated software is done
in the same manner as ensuring that the TOE is running a valid image. See Section 2 steps 1
through 5 above for the method to download and verify an image prior to running it on the TOE.
30
Clock Management
Clock management is restricted to the privileged administrator.
The Basic System Management Configuration Guide contains information on setting the local
hardware clock or NTP sources. When Network Time Protocol (NTP) is configured, the time is
synchronized with a NTP server over NTPv3. NTP runs on UDP, which in turn runs on IP. NTP
Version 3 (NTPv3) is documented in RFC 1305. In the evaluated configuration NTP
Authentication with md5 must be configured.
Configure Reference Identifier
This section describes configuration of the peer reference identifier which is achieved through a
certificate map.
Certificate maps provide the ability for a certificate to be matched with a given set of criteria.
You can specify which fields within a certificate should be checked and which values those
fields may or may not have. There are six logical tests for comparing the field with the value:
equal, not equal, contains, does not contain, less than, and greater than or equal. ISAKMP and
ikev2 profiles can bind themselves to certificate maps, and the TOE will determine if they are
valid during IKE authentication.
Step1
(config)# crypto pki certificate map
label sequence-number
Starts certificate-map mode
Step2
(ca-certificate-map)# field-name matchcriteria match-value
In ca-certificate-map mode, you specify one or more
certificate fields together with their matching criteria and the
value to match.

field-name—Specifies one of the following caseinsensitive name strings or a date:
–subject-name
–issuer-name
–unstructured-subject-name
–alt-subject-name
–name
–valid-start
–expires-on
Note Date field format is dd mm yyyy hh:mm:ss or mm dd
yyyy hh:mm:ss.

match-criteria—Specifies one of the following
logical operators:
–eq—Equal (valid for name and date fields)
–ne—Not equal (valid for name and date fields)
–co—Contains (valid only for name fields)
–nc—Does not contain (valid only for name fields)
–lt —Less than (valid only for date fields)
31
–ge —Greater than or equal (valid only for date
fields)

Step3
(ca-certificate-map)# exit
Step4
For IKEv1:
crypto isakmp profile ikev1-profile1
match certificate label
match-value—Specifies the name or date to test with
the logical operator assigned by match-criteria.
Exits ca-certificate-map mode.
Associates the certificate-based ACL defined with the crypto
pki certificate map command to the profile.
For IKEv2:
crypto ikev2 profile ikev2-profile1
match certificate label
For example: To create a certificate map for IKEv1 to match four subject-name values of the
peer enter:
# conf t
(config)# crypto pki certificate map cert-map-match-all 99
(ca-certificate-map)# subject-name co cn=CC_PEER
(ca-certificate-map)# subject-name co o=ACME
(ca-certificate-map)# subject-name co ou=North America
(ca-certificate-map)# subject-name co c=US
(ca-certificate-map)#exit
(config)# crypto isakmp profile ike1-profile-match-cert
match certificate cert-map-match-all
Identification and Authentication
Configuration of Identification and Authentication settings is restricted to the privileged
administrator.
The CSR can be configured to use any of the following authentication methods:

Remote authentication (RADIUS)
o Refer to “Authentication Server Protocols” elsewhere in this document for more
details.

Local authentication (password or SSH public key authentication);

o Note: this should only be configured for local fallback if the remote authentication
server is not available.
X.509v3 certificates
Refer to “X.509 Certificates” in Section 4.3.2 for more details.
32
5 Security Relevant Events
CSR can maintain logs in multiple locations: local storage of the generated audit records, and
when configured for a syslog backup will simultaneously offload those events to the external
syslog server. CSR administrators should review logs at both locations.
The TOE generates an audit record whenever an audited event occurs. The types of events that
cause audit records to be generated include, cryptography related events, identification and
authentication related events, and administrative events (the specific events and the contents of
each audit record are listed in Table 5 below). Each of the events is specified in syslog records
in enough detail to identify the user for which the event is associated, when the event occurred,
where the event occurred, the outcome of the event, and the type of event that occurred.
Additionally, the startup and shutdown of the audit functionality is audited.
The audit trail consists of the individual audit records; one audit record for each event that
occurred. The audit record can contain up to 80 characters and a percent sign (%), which follows
the time-stamp information. The audit fields in each audit event will contain at a minimum the
following:
Example Audit Event: Nov 19 13:55:59: %CRYPTO-6-SELF_TEST_RESULT: Self test info:
(DES encryption/decryption
... passed)
Date: Nov 19
Time: 13:55:59
Type of event: %CRYPTO-6-SELF_TEST_RESULT
Subject identity: Available when the command is run by an authorized TOE administrator user
such as “user: lab”. In cases where the audit event is not associated with an authorized user, an
IP address may be provided for the Non-TOE endpoint and/ or TOE.
IP address: (Optional) May be provided along with the subject identity of a specific authorized
TOE administrator.
Port number: (Optional) May be provided along with the IP address for throughput traffic
Outcome (Success or Failure): Success may be explicitly stated with “success” or
“passed”contained within the audit event or is implicit in that there is not a failure or error
message. More specifically for failed logins, a “Login failed” will appear in the audit event. For
successful logins, a “Login success” will appear in the associated audit event. For failed events
“failure” will be denoted in the audit event. For other audit events a detailed description of the
outcome may be given in lieu of an explicit success or failure. For example, for an IPsec session
where the lifetime of the SA has expired a detailed description is given in the associated audit
event: “SA lifetime threshold reached, expiring in 1412 seconds.”
As noted above, the information includes at least all of the required information. Example audit
events are included below:
Additional Audit Information: As described in Column 3 of Table 5 below.
33
Table 5: Auditable Events
Requirement
FCS_IPSEC_EX
T.1
Auditable
Events
Failure to
establish an
IPsec SA.
Session
establishment
with peer
Additional Audit
Record Contents
Sample Record
Reason for failure.
 Initiation of IPSEC session (outbound):
Jun 20 07:42:26.823: ISAKMP (0): received packet
from 100.1.1.5 dport 500 sport 500 Global (N) NEW
SA
Entire packet
contents of packets
transmitted/receive
d during session
establishment
Jun 20 07:42:26.823: ISAKMP: Created a peer struct
for 100.1.1.5, peer port 500
Jun 20 07:42:26.823: ISAKMP: New peer created
peer = 0x89C3879C peer_handle = 0x8000000C
Jun 20 07:42:26.823: ISAKMP: Locking peer struct
0x89C3879C, refcount 1 for
crypto_isakmp_process_block
Jun 20 07:42:26.823: ISAKMP: local port 500,
remote port 500
Jun 20 07:42:26.823: ISAKMP:(0):insert sa
successfully sa = 8C1C1FD4
Jun 20 07:42:26.823: ISAKMP:(0):Input =
IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun 20 07:42:26.823: ISAKMP:(0):Old State =
IKE_READY New State
= IKE_R_MM1 …
Jun 20 07:42:26.823: ISAKMP:(0):found peer preshared key matching 100.1.1.5
Jun 20 07:42:26.823: ISAKMP:(0): local preshared
key found
Jun 20 07:42:26.823: ISAKMP : Scanning profiles
for xauth ...
Jun 20 07:42:26.823: ISAKMP:(0):Checking
ISAKMP transform 1 against priority 1 policy
Jun 20 07:42:26.827: ISAKMP:
CBC
encryption AES-
Jun 20 07:42:26.827: ISAKMP:
keylength of 128
Jun 20 07:42:26.827: ISAKMP:
hash SHA
Jun 20 07:42:26.827: ISAKMP:
default group 14
Jun 20 07:42:26.827: ISAKMP:
auth pre-share…
Jun 20 07:42:26.843: ISAKMP (0): received packet
from 100.1.1.5 dport 500 sport 500 Global (R)
MM_SA_SETUP
34
Requirement
Auditable
Events
Additional Audit
Record Contents
Sample Record
Jun 20 07:42:26.843: ISAKMP:(0):Input =
IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun 20 07:42:26.843: ISAKMP:(0):Old State =
IKE_R_MM2 New State = IKE_R_MM3
Jun 20 07:42:26.843: ISAKMP:(0): processing KE
payload. message ID = 0
Jun 20 07:42:27.055: ISAKMP:(0): processing
NONCE payload. message ID = 0
Jun 20 07:42:27.059: ISAKMP:(0):found peer preshared key matching 100.1.1.5

Termination of IPSEC session (outboundinitiated)
.Jun 19 21:09:49.619: IPSEC(delete_sa): deleting
SA,
(sa) sa_dest= 100.1.1.5, sa_proto= 50,
sa_spi= 0x3C81B171(1015132529),
sa_trans= esp-aes esp-sha-hmac ,
sa_conn_id=
62
sa_lifetime(k/sec)= (4608000/28800),
(identity) local= 100.1.1.1:0, remote= 100.1.1.5:0,
local_proxy= 10.1.1.0/255.255.255.0/256/0,
remote_proxy= 12.1.1.0/255.255.255.0/256/0
Jun 19 21:10:37.575: ISAKMP:(2034):purging node 506111676
.Jun 19 21:10:39.615:
ISAKMP:(2034):purging node -22679511
.Jun 20 04:46:14.789:
IPSEC(lifetime_expiry): SA lifetime threshold
reached, expiring in 1412 seconds

Failure of an established IPSEC session
(outbound-initiated)
Jun 19 11:12:33.905: %CRYPTO-5IKMP_AG_MODE_DISABLED: Unable to initiate
or respond to Aggressive Mode while disabled
Configuration of IPsec:
1/3
1/1
3
1/3
0/1
3
35
8:2
6:3
2
11:
04:
42
Inf
o
No
tic
e
Jan 30 18:56:50 10.104.49.55 Time set to Jan
18:56:50, from server 10.104.49.22.
131: *Jan 30 2013 05:20:15: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:logging trap 7
Requirement
Auditable
Events
Additional Audit
Record Contents
Sample Record
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
1/3
0/1
3
FCS_SSHS_EX
T.1
Failure to
establish an SSH
session
Reason for Failure
11:
04:
43
11:
09:
13
11:
09:
13
11:
11:
58
11:
12:
08
11:
11:
58
11:
12:
08
11:
11:
58
11:
12:
08
11:
11:
58
No
tic
e
De
bu
g
De
bu
g
No
tic
e
No
tic
e
No
tic
e
No
tic
e
No
tic
e
No
tic
e
No
tic
e
132: *Jan 30 2013 05:20:16: %SYS-5-CONFIG_
Configured from console by console
136: *Jan 30 10:54:46.421 IST: crypto_engine
IPsec SA
135: *Jan 30 10:54:46.421 IST: crypto engine:
IPsec SA :12
171: *Jan 30 2013 05:27:31: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:no crypto map
172: *Jan 30 2013 05:27:42: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:crypto map cc
171: *Jan 30 2013 05:27:31: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:no crypto map
172: *Jan 30 2013 05:27:42: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:crypto map cc
171: *Jan 30 2013 05:27:31: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:no crypto map
172: *Jan 30 2013 05:27:42: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:crypto map cc
171: *Jan 30 2013 05:27:31: %PARSER-5CFGLOG_LOGGEDCMD: User:console logged
command:no crypto map

*Feb 22 2017 13:48:41.418: \%SSH-3NO_MATCH: No matching cipher found: client
3des-cbc server aes128-cbc,aes256-cbc

*Feb 22 2017 13:43:27.213: \%SEC_LOGIN-4LOGIN_FAILED: Login failed [user: ] [Source:
10.41.0.101] [localport: 22] [Reason: Login
Authentication Failed] at 13:43:27 EST Wed Feb
22 2017
*Feb 9 2017 11:03:17.322: \%AAA-5USER_LOCKED: User testuser locked
out on authentication failure
FIA_AFL.1
Administrator
lockout due to
excessive
authentication
failures
None.

FIA_UIA_EXT.
1
All use of the
identification
Provided user
identity, origin of
See Audit events in FIA_UAU_EXT.2
36
Requirement
FIA_UAU_EXT.
2
Auditable
Events
Additional Audit
Record Contents
and
authentication
mechanism.
the attempt (e.g., IP
address).
All use of the
authentication
mechanism.
Origin of the
attempt (e.g., IP
address).
Sample Record

Login as an administrative user at the console
Username: auditperson
Password:
CSR1000v>?
000278: *Apr 23 07:11:56: %SEC_LOGIN-5LOGIN_SUCCESS: Login Success [user:
auditperson] [Source: 0.0.0.0] [localport: 0] at
07:11:56 UTC Thu Apr 23 2009?

Failed login via the console does not allow any
actions
Username: auditperson
Password:
% Authentication failed
Username:
000254: *Apr 26 00:45:43.340: %SEC_LOGIN-4LOGIN_FAILED: Login failed [user: auditperson]
[Source: 0.0.0.0] [localport: 0] [Reason: Login
Authentication Failed] at 23:45:43 a Sat Apr 25 2009

Successful login via ssh
Mar 24 07:30:02.488: \%SEC_LOGIN-5LOGIN_SUCCESS: Login Success [user: admin15]
[Source: 10.21.0.101] [localport: 22] at 07:30:02
EDT Tue Mar 24 2015

Failed login via ssh
Mar 24 07:29:59.480: \%SEC_LOGIN-4LOGIN_FAILED: Login failed [user: admin15]
[Source: 10.21.0.101] [localport: 22] [Reason: Login
Authentication Failed] at 07:29:59 EDT Tue Mar 24
2015
FIA_X509_EXT
.1
Unsuccessful
attempt to
validate a
certificate
Reason for failure
37

Feb 7 2017 00:10:51.382: ../certc/source/vericert.c(145) :
E_INVALID_SIGNATURE : error verifying
digitial signature
Requirement
Auditable
Events
Additional Audit
Record Contents
Session
establishment
with CA
Entire packet
contents of packets
transmitted/receive
d during session
establishment
Sample Record
Feb 7 2017 00:10:51.382: I
../VIEW_ROOT/cisco.comp/pki_ssl/src/ca/provi
der/path/pkix/pkixpath.c(1087) : Error #72Eh
Feb 7 2017 00:10:51.382: CRYPTO_PKI:
(A0004) Certificate is not verified

*Feb 1 2017 18:42:26.066: CRYPTO_PKI:
(A0003) Using ca-root to validate certificate
*Feb 1 2017 18:42:26.068: CRYPTO_PKI:
(A0003) Certificate is verified
*Feb 1 2017 18:42:26.068: CRYPTO_PKI:
(A0003) Certificate validated without revocation
check
*Feb 1 2017 18:42:26.068: CRYPTO_PKI:
(A0003) Certificate validation succeeded
FMT_MOF.1(1)/
TrustedUpdate
Any attempt to
initiate a manual
update
None.

12-13-2017 14:37:30 Syslog.Notice
10.1.2.25
1486: *Dec 13
19:37:20.631: %PARSER-5CFGLOG_LOGGEDCMD: User:acumensec
logged command:boot system flash:
FMT_MTD.1
All Management
activities of the
TSF data
None.

12-13-2017 14:37:48 Syslog.Notice
10.1.2.25
1488: *Dec 13
19:37:37.958: %SYS-5-CONFIG_I: Configured
from console by acumensec on vty0
(192.168.254.208)
Application of
rules configured
with the ‘log’
operation
Source and
destination
addresses

Mar 7 20:33:45 toe-loopback 5597: Mar 7 2017
20:33:44.249: \%FMANFP-6-IPACCESSLOGP:
SIP0: fman_fp_image: list
FPF_RUL_EXT.1.7.T9-permit permitted udp
10.42.0.203(500) GigabitEthernet0/0/1->
10.41.0.101(500), 1 packet
Mar 7 20:33:45 toe-loopback 5598: Mar 7 2017
20:33:44.499: \%FMANFP-6-IPACCESSLOGP:
SIP0: fman_fp_image: list
FPF_RUL_EXT.1.7.T9-permit permitted udp
10.42.0.203(501) GigabitEthernet0/0/1->
10.41.0.101(501), 1 packet
Mar 7 20:34:11 toe-loopback 5599: Mar 7 2017
20:34:10.778: \%HA_EM-6-LOG: cli_log:
User:script via Port:0 Executed[show access-lists
FPF_RUL_EXT.1.7.T9-permit ]
Mar 7 20:34:11 toe-loopback 5600: Mar 7 2017
20:34:11.137: \%HA_EM-6-LOG: cli_log:
User:script via Port:0 Executed[show access-lists
FPF_RUL_EXT.1.7.T9-permit
Mar 7 20:34:11 toe-loopback 5600: Mar 7 2017
20:34:11.137: \%HA_EM-6-LOG: cli_log: value
GigabitEthernet0/0/1 output_packets_dropped
increased from 1025456 to 1043265
FPF_RUL_EXT.
1
Indication of
packets dropped
due to too much
network traffic
Source and
destination ports

Transport Layer
Protocol
TOE Interface that
is unable to process
packets



38
Requirement
FPT_STM.1
Auditable
Events
Changes to the
time.
Additional Audit
Record Contents
The old and new
values for the time.
Origin of the
attempt to change
time for success
and failure (e.g., IP
address).
Sample Record
++++ 14:18:21 CSR1000V Control::transmit +++
Transmit: show logging | include CLOCKUPDATE
+--- 14:18:21 --++++ 14:18:21 CSR1000V Control::receive +++
show logging | include CLOCKUPDATE
Mar 18 13:18:19.639: \%SYS-6-CLOCKUPDATE:
System clock has been updated from 14:18:19 EDT
Wed Mar 18 2015 to 13:18:19 EDT Wed Mar 18
2015, configured from console by script on console.
CSR1000V #
--- 14:18:36 --.Dec 22 22:22:35.812: NTP message sent to
10.24.0.1, from interface 'GigabitEthernet0/0/0'
(10.21.0.110).
.Dec 22 22:22:35.812: NTP message received from
10.24.0.1 on interface 'GigabitEthernet0/0/0'
(10.21.0.110).
.Dec 22 22:22:35.812: NTP Core(DEBUG):
ntp_receive: message received
.Dec 22 22:22:35.812: NTP Core(DEBUG):
ntp_receive: peer is 0x7FD044C809B0, next action is
1.
.Dec 22 22:22:35.812: NTP Core(DEBUG): Peer
becomes reachable, poll set to 6.
.Dec 22 22:22:35.812: NTP Core(INFO): 10.24.0.1
8014 84 reachable
.Dec 22 22:22:35.812: NTP Core(INFO): 10.24.0.1
902D 8D popcorn popcorn
.Dec 22 22:22:37.112: \%HA_EM-6-LOG: cli_log:
host[CSR1000V] user[script] port[0] exec_lvl[15]
command[show ntp status ] Executed
.Dec 22 22:22:37.811: NTP message sent to
10.24.0.1, from interface 'GigabitEthernet0/0/0'
(10.21.0.110).
.Dec 22 22:22:37.812: NTP message received from
10.24.0.1 on interface 'GigabitEthernet0/0/0'
(10.21.0.110).
.Dec 22 22:22:37.812: NTP Core(DEBUG):
ntp_receive: message received
.Dec 22 22:22:37.812: NTP Core(DEBUG):
ntp_receive: peer is 0x7FD044C809B0, next action is
1.
.Dec 22 22:22:37.812: NTP Core(INFO): 10.24.0.1
963A 8A sys_peer
.Dec 22 22:22:37.812: NTP:
step(0xF164A290.06E65E00): local_offset =
0x00000000.00000000, curtime =
0xE74F9D7D.CFDF3DA0
.Mar 18 14:18:53.838: NTP Core(NOTICE): trans
state : 5
39
Requirement
FPT_TUD_EXT.
1
Auditable
Events
Initiation of
update.
Additional Audit
Record Contents
Sample Record

No additional
information.
Use of the “upgrade” command.
*Jul 10 11:04:09.179: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco logged
command:upgrade
result of the
update attempt
(success or
failure)
*Jul 10 11:04:09.179: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco logged
command:copy tftp ….
FPT_TST_EXT.
2
Failure of selftest
Reason for failure
(including
identifier of invalid
certificate)
FTA_SSL_EXT.
1
Any attempts at
unlocking of an
[local]
interactive
session.
No additional
information.
*Jul 10 11:04:09.179: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco logged
command:reload
 %CRYPTO-0-SELF_TEST_FAILURE:
Encryption self-test failed (<failing test
description>) where <failing test
description>
In the TOE this is represented by login attempts that
occur after the timeout of a local administrative user.
001383: May 10 18:06:34.091: %SYS-6EXEC_EXPIRE_TIMER: (tty 0 (0.0.0.0)) exectimeout timer expired for user securityperson
001384: May 10 18:06:34.091: %SYS-6EXIT_CONFIG: User securityperson has exited tty
session 0(0.0.0.0)
FTA_SSL.3
The termination
of a remote
session by the
session locking
mechanism.
No additional
information.
Audit record generated when SSH session is
terminated because of idle timeout:
May 29 2012 15:18:00 UTC: %SYS-6TTY_EXPIRE_TIMER: (exec timer expired, tty 0
(0.0.0.0)), user admin
FTA_SSL.4
The termination
of an interactive
session.
No additional
information.

Initiation of the
trusted channel.
Termination of
the trusted
channel.
Identification of
the initiator and
target of failed
trusted channels
establishment
attempt.
FTP_ITC.1
Audit record generate when admin logs out of
CONSOLE.
May 17 2011 16:29:09: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin logged
command:exit
 Audit record generated when the admin logs out
of SSH:
Jun 18 11:17:36.653: SSH0: Session terminated
normally
AUDIT: See logs provided by FCS_IPSEC_EXT.1.
40
Requirement
Auditable
Events
Additional Audit
Record Contents
Sample Record
Failure of the
trusted channel
functions.
FTP_TRP.1
Initiation of the
trusted channel.
Termination of
the trusted
channel.
Failures of the
trusted path
functions.
Identification of
the claimed user
identity.
AUDIT: See logs provided by FCS_SSHS_EXT.1.
Table 6 Auditable Administrative Events
Requirement
Management Action to
Log
Sample Log
FAU_GEN.1: Audit data generation
Changing logging
settings.
Feb 17 2013 16:29:07: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command:logging enable
Clearing logs.
Feb 17 2013 16:34:02: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command:logging informational
Feb 17 2013 17:05:16: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command:clear logging
FAU_GEN.2: User identity
association
None
N/A
FAU_STG_EXT.1: Protected Audit
Event Storage
Configuration of syslog
export settings
Feb 17 2013 17:05:16: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command:logging host
FCS_CKM.1: Cryptographic key
generation (refined)
Manual key generation
Feb 17 2013 16:14:47: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command:crypto key *****
41
Requirement
Management Action to
Log
Sample Log
Jan 24 2013 03:10:08.878: %GDOI-5KS_REKEY_TRANS_2_UNI: Group getvpn
transitioned to Unicast Rekey.ip
FCS_CKM.1/IKE:
Cryptographic
Key Generation (for IKE peer
authentication)
Manual key generation
Feb 17 2013 16:14:47: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command:crypto key *****
Jan 24 2013 03:10:08.878: %GDOI-5KS_REKEY_TRANS_2_UNI: Group getvpn
transitioned to Unicast Rekey.ip
FCS_CKM.2: Cryptographic Key
Establishment (Refined)
None
N/A
FCS_CKM.4: Cryptographic key
destruction
None
N/A
FCS_COP.1(1): Cryptographic
operation (AES data
encryption/decryption)
None
N/A
FCS_COP.1(2): Cryptographic
operation (Signature Generation and
Verification)
None
N/A
FCS_COP.1(3): Cryptographic
operation (Hash Algorithm)
None
N/A
FCS_COP.1(4): Cryptographic
operation (for keyed-hash message
authentication)
None
N/A
FCS_RBG_EXT.1: Cryptographic
operation (random bit generation)
None
N/A
FCS_IPSEC_EXT.1.1 Extended:
IPSEC
Configuration of IPsec
settings: including
mode, security policy,
IKE version, algorithms,
lifetimes, DH group,
and certificates.
ESP-Algorithms:
*Mar 13 11:56:12.491: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:interface
GigabitEthernet0/0/1
42
Requirement
Management Action to
Log
Sample Log
*Mar 13 11:56:15.762: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip access-list extended acl_
CSR1000V
*Mar 13 11:56:16.407: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:permit icmp 10.21.0.0
0.0.0.255 10.22.05.0 0.0.0.255
*Mar 13 11:56:16.690: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto ipsec transform-set
set_1 esp-gcm 128
*Mar 13 11:56:16.779: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:mode tunnel
*Mar 13 11:56:18.195: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto ikev2 policy
ikev2_policy_1
*Mar 13 11:56:20.618: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:authentication local preshare
*Mar 13 11:56:20.756: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:authentication remote preshare
Mar 13 11:59:19.529: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:encryption aes-cbc-256
Mar 13 11:59:19.745: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:group 14
43
Requirement
Management Action to
Log
Sample Log
Mar 13 12:11:01.999: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:integrity sha256
*Mar 13 11:56:21.109: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto map cmap_1 1 ipsecisakmp
*Mar 13 11:56:21.344: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:set peer 10.22.0.2
*Mar 13 11:56:21.471: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:set transform-set set_1
*Mar 13 11:56:21.737: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:match address acl_
CSR1000V
*Mar 13 11:56:22.512: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip route 10.22.05.0
255.255.255.0 10.22.0.2
IKEv2-SA-Lifetime:
Mar 14 23:16:24.170: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto ipsec securityassociation lifetime kilobytes 10240
IKEv2-DH:
Jan 16 00:36:43 cc_toe 279: *Jan 16
00:36:43.032: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto ikev2 proposal
ike2aes2sha2
Jan 16 00:36:43 cc_toe 283: *Jan 16
00:36:43.509: \%PARSER-5-
44
Requirement
Management Action to
Log
Sample Log
CFGLOG_LOGGEDCMD: User:script
logged command:integrity sha256
Jan 16 00:36:44 cc_toe 291: *Jan 16
00:36:44.046: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:proposal ike2aes2sha2
Jan 16 00:36:44 cc_toe 293: *Jan 16
00:36:44.182: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto ikev2 keyring
keyring1
Jan 16 00:36:44 cc_toe 299: *Jan 16
00:36:44.570: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:pre-shared-key 0 Cisco123
Jan 16 00:36:44 cc_toe 301: *Jan 16
00:36:44.712: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:crypto ikev2 profile profile1
FCS_SSHS_EXT.1: SSH Server
Protocol
Configuration of SSH
settings: including
certificates or
passwords, algorithms,
host names, users.
*Feb 4 15:02:06.415: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip ssh version 2
*Feb 4 15:02:06.531: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip ssh dh min size 2048
*Feb 4 15:02:06.644: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip ssh logging events
FIA_AFL.1 Authentication Failure
Handling
Administrator lockout
due
to
excessive
authentication failures
45
Feb 17 2013 16:14:47: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command: aaa local authentication
attempts max-fail [number of failures]
Requirement
Management Action to
Log
Sample Log
Feb 7 2013 02:05:41.953: %AAA-5USER_UNLOCKED: User user unlocked by
admin on vty0 (21.0.0.1)
FIA_PMG_EXT.1: Password
management
None
None
FIA_PSK_EXT.1: Extended: PreShared Key Composition
Creation of a pre-shared
key.
Feb 15 2013 13:12:25.055: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco
logged command: crypto isakmp key *****
FIA_UIA_EXT.1: User
identification and authentication
Logging into TOE.
Jan 17 2013 05:05:49.460: %SEC_LOGIN-5LOGIN_SUCCESS: Login Success [user:
ranger] [Source: 21.0.0.3] [localport: 22] at
00:05:49 EST Thu Jan 17 2013
FIA_UAU_EXT.2: Password-based
authentication mechanism
None
N/A
FIA_UAU.7: Protected
authentication feedback
None
N/A
FIA_X509_EXT.1: X.509
Certificate Validation
Generating a certificate
Feb 17 2013 16:14:47: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command: crypto key generate
FIA_X509_EXT.2:
Authentication
Certificate
FIA_X509_EXT.3:
Requests
Certificate
FIA_X509_EXT.4:
Identity
Certificate
FMT_MOF.1(1)/AdminAct:
Management of Security Functions
Behavior
Configuring PKI
trustpoint
Feb 17 2013 16:12:47: %PARSER-5CFGLOG_LOGGEDCMD: User:test_admin
logged command: crypto pki trustpoint
See all other rows in
table.
N/A
See all other rows in
table.
N/A
FMT_MOF.1(1)/TrustedUpdate:
Management of Security Functions
Behavior
FMT_MTD.1: Management of TSF
data
46
Requirement
Management Action to
Log
Sample Log
FMT_SMF.1: Specification of
management functions
See all other rows in
table.
N/A
FMT_SMR.2: Restrictions on
Security roles
Configuring
administrative users
with specified roles.
Feb 15 2013 13:12:25.055: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco
logged command: username admin 15
FPF_RUL_EXT.1: Packet Filtering
Configuring packet
filtering rules.
Oct 15 23:39:50 cc_toe 21698: Oct 15
23:39:50.077: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:permit icmp 10.32.0.203
0.0.0.0 10.31.0.101 0.0.0.0 log
FMT_MTD.1/AdminAct:
Management of TSF data
Oct 15 23:39:50 cc_toe 21700: Oct 15
23:39:50.261: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:deny icmp 10.32.0.203
0.0.0.0 10.31.0.101 0.0.0.0 log
Oct 15 23:39:50 cc_toe 21696: Oct 15
23:39:49.881: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip access-list extended
FPF_RUL_EXT.1.6.T1-permit
Oct 15 23:39:50 cc_toe 21704: Oct 15
23:39:50.625: \%PARSER-5CFGLOG_LOGGEDCMD: User:script
logged command:ip access-group
FPT_FLS.1: Fail Secure
None
N/A
FPT_SKP_EXT.1: Protection of
TSF Data (for reading of all
symmetric keys)
None
N/A
FPT_APW_EXT.1: Protection of
Administrator Passwords
None
N/A
47
Requirement
Management Action to
Log
Sample Log
FPT_STM.1: Reliable time stamps
Changes to NTP
settings.
Changes to NTP settings:
Manual changes to the
system time.
Manual changes to the system time:
Feb 5 2013 06:28:00.000: %SYS-6CLOCKUPDATE: System clock has been
updated from 11:27:52 UTC Tue Feb 5 2013
to 06:28:00 UTC Tue Feb 5 2013, configured
from console by admin on console.
FPT_TUD_EXT.1: Trusted update
Software updates
Jul 10 2013 11:04:09.179: %PARSER-5CFGLOG_LOGGEDCMD:
User:cisco logged command:upgrade
FPT_TST_EXT.1: TSF testing
None
N/A
FTA_SSL_EXT.1: TSF-initiated
session locking
Specifying the inactivity
time period.
Feb 15 2013 13:12:25.055: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco
logged command: exec-timeout 60
FTA_SSL.3: TSF-initiated
termination
Specifying the inactivity
time period.
Feb 15 2013 13:12:25.055: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco
logged command: exec-timeout 60
FTA_SSL.4: User-initiated
termination
Logging out of TOE.
Feb 15 2013 13:12:25.055: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco
logged command: exit
FTA_TAB.1: Default TOE access
banners
Configuring the banner
displayed prior to
authentication.
Feb 15 2013 13:12:25.055: %PARSER-5CFGLOG_LOGGEDCMD: User:cisco
logged command: banner login d This is a
banner d
FTP_ITC.1: Inter-TSF trusted
channel
None
N/A
FTP_TRP.1: Trusted path
Connecting to the TOE
with SSH.
Jan 17 05:05:49.460: %SEC_LOGIN-5LOGIN_SUCCESS: Login Success [user:
ranger] [Source: 21.0.0.3] [localport: 22] at
00:05:49 EST Thu Jan 17 2013
48
Deleting Audit Records
The TOE provides the privileged Administrator the ability to delete audit records stored within
the TOE.
This is done with the clear logging command. See the Cisco IOS Configuration Fundamentals
Command References.
6 Network Protocols and Cryptographic Settings
Remote Administration Protocols
All TOE administration must be performed through an IPsec tunnel. However, it is
recommended that the interactive interface be over SSH. The following method is used to
configure SSH for use in a secure manner.
To only allow ssh for remote administrator sessions, use the transport input ssh command.
This command disables telnet by only allowing ssh connections for remote administrator access.
For Common Criteria compliance an IPsec session must be established either peer to peer or
IPsec client to CSR for the ssh session to go over. See section 6.1.2 for peer to peer IPsec
configuration steps.
Steps to configure SSH on router:
1. Generate RSA or ECDSA key material– choose a longer modulus length for the
evaluated configuration (i.e., 2048 for RSA and 256 or 384 for ECDSA):
TOE-common-criteria(config)# crypto key generate rsa
How many bits in the modulus [512]: 2048
or
TOE-common-criteria(config)# crypto key generate ec keysize [256 or 384]
RSA and ECDSA keys are generated in pairs—one public key and one private key. This
command is not saved in the router configuration; however, the 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.
Note: Only one set of keys can be configured using the crypto key generate command at
a time. Repeating the command overwrites the old keys.
Note: If the configuration is not saved to NVRAM with a “copy run start”, the generated
keys are lost on the next reload of the router.
49
Note: If the error “% Please define a domain-name first” is received, enter the command
‘ip domain-name [domain name]’.
2. Enable ssh
TOE-common-criteria# ip ssh authentication-retries 2
3. Configure –ssh timeout
TOE-common-criteria# ip ssh time-out 60
4. Set to use SSH v2
TOE-common-criteria# ip ssh version 2
5. Ensure that the product is configured not to support diffie-hellman-group1-sha1 key
exchange using the following command ‘ip ssh dh min size 2048’:
TOE-common-criteria(config)# ip ssh dh min size 2048
6. Configure vty lines to accept ‘ssh’ login services
TOE-common-criteria(config-line)# transport input ssh
7. Configure a SSH client to support only the following specific encryption algorithms:
o AES-CBC-128
o AES-CBC-256
peer#ssh -l cisco -c aes128-cbc 1.1.1.1
peer#ssh -l cisco -c aes256-cbc 1.1.1.1
8. Configure a SSH client to support message authentication. Only the following MACs are
allowed and “None” for MAC is not allowed:
a. hmac-sha1-96
b. hmac-sha1
peer#ssh -l cisco -m hmac-sha1-96 1.1.1.1
9. Configure the SSH rekey time-based rekey and volume-based rekey values (values can be
configured to be lower than the default values if a shorter interval is desired):
a. ip ssh rekey time 60
b. ip ssh rekey volume 1000000



When configuring an SSH rekey time or volume interval, the TOE will begin re-key
based upon the first threshold reached
HTTP and HTTPS servers were not evaluated and must be disabled: no ip http server
no ip http secure-server
SNMP server was not evaluated and must be disabled: no snmp-server
Steps to configure IPsec peer to peer on router:
50
The configurations below enable the remote VPN peer to connect to the TOE. The steps do the
following:







Create a loopback interface on both devices with an IP on a distinct subnet.
Create crypto acls to send all traffic between the two loopbacks through the ipsec tunnel.
Create settings for the tunnel.
Create the route between the two loopback IP’s.
Set the source address for SSH sessions from the peer to be the loopback.
Create and apply an access class acl on the vty to only permit ssh from the peer source ip
Create and apply an acls on all external interfaces to deny ssh traffic
The following configuration is an example TOE configured to only allow SSH through a VPN.
ip ssh source-interface Loopback0
ip ssh version 2
ip ssh dh min size 2048
!
!
!
crypto isakmp policy 77
encr aes
authentication pre-share
group 14
crypto isakmp key cisco123 address 192.168.2.37
!
!
crypto ipsec transform-set cc-tset esp-aes esp-sha-hmac
mode tunnel
!
!
!
!
!
crypto map cc-csr 77 ipsec-isakmp
set peer 192.168.2.37
51
set transform-set cc-tset
match address 178
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 192.168.5.33 255.255.255.0
!
interface GigabitEthernet0/0/0
ip address 192.168.2.33 255.255.255.0
ip access-group 111 in
media-type rj45
negotiation auto
cdp enable
crypto map cc-csr
!
no ip http server
no ip http secure-server
ip route profile
ip route 192.168.4.0 255.255.255.0 192.168.2.37
!
access-list 11 permit 192.168.4.37
access-list 111 deny tcp any any eq 22
access-list 111 permit ip any any
access-list 178 permit ip 192.168.5.0 0.0.0.255 192.168.4.0 0.0.0.255
cdp run
52
!
!
!
!
control-plane
!
!
!
!
line vty 0 4
access-class 11 in
!
!
end
Logging Configuration
Logging of command execution must be enabled: [10] Cisco IOS Configuration Fundamentals
Command Reference and Cisco IOS Debug Command References
1. Logging of command execution must be enabled:
TOE-common-criteria(config)#archive
TOE-common-criteria(config)#no logging console
TOE-common-criteria(config-archive)#log config
TOE-common-criteria(config-archive-log-cfg)#logging enable
TOE-common-criteria(config-archive-log-cfg)#hidekeys
TOE-common-criteria(config-archive-log-cfg)# logging size <1000> ! Increases queue
size for messages to be sent to syslogd
TOE-common-criteria(config-archive-log-cfg)#notify syslog
TOE-common-criteria(config-archive-log-cfg)#exit
TOE-common-criteria(config-archive)#exit
2. Add year to the timestamp:
TOE-common-criteria(config)# service timestamps log datetime year
TOE-common-criteria(config)# service timestamps debug datetime year
3. Enable any required debugging. Debugging is needed for radius (if used), isakmp (if
using ikev1), ipsec, ikev2 (if using ikev2), and ntp to generate the events required in the
Security Target, however administrators should use discretion when enabling a large
number of debugs on an on-going basis:
53
TOE-common-criteria# debug radius authentication
TOE-common-criteria# debug crypto isakmp
TOE-common-criteria# debug crypto ipsec
TOE-common-criteria# debug crypto ikev2
TOE-common-criteria# debug ntp all
TOE-common-criteria# debug crypto pki server
4. Set the size and severity of the local logging buffer. The local logging buffer size can be
configured from a range of 4096 (default) to 2,148,483,647 bytes. It is noted to not make
the buffer size too large because the TOE could run out of memory for other tasks. It is
recommended to set it to at least 150000000:
TOE-common-criteria(config)# logging buffer 150000000
TOE-common-criteria(config)# logging buffer debug
5. To generate logging messages for failed and successful login attempts in the evaluated
configuration, issue the login on-failure and login on-success commands:
TOE-common-criteria(config)#login on-failure log
TOE-common-criteria(config)#login on-success log
6. To configure the logs to be sent to a syslog server:
TOE-common-criteria(config)# logging host <ip address of syslog server>
Ex. TOE-common-criteria(config)# logging host 192.168.202.169
7. To specify the severity level for logging to the syslog host, use the logging trap
command. Level 7 will send all logs required in the evaluation up to the debug level logs
(as enabled in step 3 above) to the syslog server:
TOE-common-criteria(config)# logging trap 7
WARNING: this setting has the ability to generate a large number of events that could
affect the performance of your device, network, and syslog host.
Logging Protection
If an authorized administrator wants to backup the logs to a syslog server, then protection must
be provided for the syslog server communications. This can be provided in one of two ways:
1. With a syslog server operating as an IPsec peer of the TOE and the records tunneled over
that connection, or
2. With a syslog server is not directly co-located with the TOE, but is adjacent to an IPsec
peer within a trusted facility, and the records are tunneled over the public network.
Syslog Server Running on an IPsec Endpoint
For deployments where the syslog server is able to operate as an IPsec peer of the TOE, the
IPsec tunnel will protect events as they are sent to the server. Examples of products that can be
installed on a syslog server to allow it to be an IPsec peer include the Racoon tool that is part of
the IPsec Tools on many Linux systems, strongSwan, Openswan, and FreeS/WAN.
Following are sample instructions to configure the TOE to support an IPsec tunnel with aes
encryption, with 10.10.10.101 as the IPsec peer IP on the syslog server, 10.10.10.110 and
54
30.0.0.1 as the local TOE IPs, and the syslog server running on 40.0.0.1 (a separate interface on
the syslog server). For the following commands see the [10] Cisco IOS Configuration
Fundamentals Command References, and Cisco IOS Security Command References.
TOE-common-criteria# configure terminal
TOE-common-criteria(config)#crypto isakmp policy 1
TOE-common-criteria(config-isakmp)#encryption aes
TOE-common-criteria(config-isakmp)#authentication pre-share
TOE-common-criteria(config-isakmp)#group 14
TOE-common-criteria(config-isakmp)#lifetime 28800
TOE-common-criteria(config)#crypto isakmp key [insert 22 character preshared key]
address 10.10.10.101
TOE-common-criteria(config)#crypto isakmp key [insert 22 character preshared key]
address 40.0.0.1
TOE-common-criteria(config)#crypto ipsec transform-set sampleset esp-aes esp-shahmac
TOE-common-criteria(cfg-crypto-trans)#mode tunnel
TOE-common-criteria(config)#crypto map sample 19 ipsec-isakmp
TOE-common-criteria(config-crypto-map)#set peer 10.10.10.101
TOE-common-criteria(config-crypto-map)#set transform-set sampleset
TOE-common-criteria(config-crypto-map)#set pfs group14
TOE-common-criteria(config-crypto-map)#match address 170
TOE-common-criteria(config-crypto-map)#exit
TOE-common-criteria(config)#interface g0/0
TOE-common-criteria(config-if)#ip address 10.10.10.110 255.255.255.0
TOE-common-criteria(config-if)#crypto map sample
TOE-common-criteria(config-if)#interface Loopback1
TOE-common-criteria(config-if)#ip address 30.0.0.1 255.0.0.0
TOE-common-criteria(config-if)#exit
TOE-common-criteria(config)# ip route 40.0.0.0 255.0.0.0 10.10.10.101
TOE-common-criteria(config)# access-list 170 permit ip 30.0.0.0 0.255.255.255
40.0.0.0 0.255.255.255
TOE-common-criteria(config)#logging source-interface Loopback1
TOE-common-criteria(config)#logging host 40.0.0.1
Syslog Server Adjacent to an IPsec Peer
If the syslog server is not directly co-located with the TOE, then the syslog server must be
located in a physically protected facility and connected to a router capable of establishing an
IPsec tunnel with the TOE. This will protect the syslog records as they traverse the public
network.
Following are sample instructions to configure the TOE to support an IPsec tunnel with aes
encryption, with 11.1.1.4 as the IPsec peer, 10.1.1.7 and 11.1.1.6 as the local IPs, and the syslog
server on the 12.1.1.0 /28 subnet.
55
For the following commands see the [10] Cisco IOS Configuration Fundamentals Command
References, and Cisco IOS Security Command References:
TOE-common-criteria#configure terminal
TOE-common-criteria(config)#crypto isakmp policy 1
TOE-common-criteria(config-isakmp)#encryption aes
TOE-common-criteria(config-isakmp)#authentication pre-share
TOE-common-criteria(config-isakmp)#group 14
TOE-common-criteria(config-isakmp)#lifetime 28800
TOE-common-criteria(config)#crypto isakmp key [insert 22 character preshared key]
address 10.10.10.101
TOE-common-criteria(config)#crypto isakmp key [insert 22 character preshared key]
address 40.0.0.1
TOE-common-criteria(config)#crypto ipsec transform-set sampleset esp-aes esp-shahmac
TOE-common-criteria(cfg-crypto-trans)#mode tunnel
TOE-common-criteria(config)#crypto map sample 1 ipsec-isakmp
TOE-common-criteria(config-crypto-map)#set peer 11.1.1.4
TOE-common-criteria(config-crypto-map)#set transform-set sampleset
TOE-common-criteria(config-crypto-map)#match address 115
TOE-common-criteria(config-crypto-map)#exit
TOE-common-criteria(config)#interface g0/1
TOE-common-criteria(config-if)#ip address 10.1.1.7 255.255.255.0
TOE-common-criteria(config-if)#no ip route-cache
TOE-common-criteria(config-if)#crypto map sample
TOE-common-criteria(config-if)#interface g0/0
TOE-common-criteria(config-if)#ip address 11.1.1.6 255.255.255.0
TOE-common-criteria(config-if)#crypto map sample
TOE-common-criteria(config-if)#exit
TOE-common-criteria(config)#ip route 12.1.1.0 255.255.255.0 11.1.1.4
TOE-common-criteria(config)#access-list 115 permit ip 10.1.1.0 0.0.0.255 12.1.1.0
0.0.0.255 log
TOE-common-criteria(config)#logging host 12.1.1.1
Base Firewall Rule set Configuration
The Network Device PP VPN Gateway Extended Package (VPNGW EP) contains requirements
for the TOE basic packet filtering. Packet filtering is able to be done on many protocols by the
TOE, including but not limited to:
o IPv4 (RFC 791)
o IPv6 (RFC 2460)
o TCP (RFC 793)
o UDP (RFC 768)
o IKEv1 (RFCs 2407, 2408, 2409, RFC 4109)
56
o IKEv2 (RFC 5996)
o IPsec ESP (RFCs 4301, 4303)
o SSH (RFCs 4251, 4252, 4253, and 4254)
The following attributes, at a minimum, are configurable within Packet filtering rules for the
associated protocols:

IPv4
o Source address
o Destination Address
o Protocol

IPv6
o Source address
o Destination Address
o Next Header (Protocol)

TCP
o Source Port
o Destination Port

UDP
o Source Port
o Destination Port
Traffic matching is done based on a top-down approach in the access list. The first entry that a
packet matches will be the one applied to it. The VPNGW EP requires that the TOE Access
control lists (ACLs) are to be configured to drop all packet flows as the default rule and that
traffic matching the acl be able to be logged. The drop all default rule can be achieved by
including an ACL rule to drop all packets as the last rule in the ACL configuration. The logging
of matching traffic is done by appending the key word “log-input” per the command reference at
the end of the acl statements, as done below.
A privileged authorized administrator may manipulate the ACLs using the commands ip inspect,
access-list, crypto map, and access-group as described in [10]
Access lists must be configured on the TOE to meet the requirements of the VPN Gateway
Extended Package.
Note: These access lists must be integrated with the defined security policy for your TOE
router. Enabling just these access lists with no permits will result in traffic being dropped.
Ensure that your access list entries are inserted above the default deny acl.
57
In this example, we are assuming that interface GigabitEthernet0/0 is the external interface, and
is assigned an IP address of 10.200.1.1. Interface GigabitEthernet0/1 is the internal interface and
is assigned an IP address of 10.100.1.1.
If remote administration is required, ssh has to be explicitly allowed through either the internal or
external interfaces.
TOE-common-criteria# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
TOE-common-criteria(config)# access-list 199 permit tcp host 10.200.0.1 host
10.200.0.1 eq 22 log-input
To log connections to the Certificate Authority, implement the following acl:.
TOE-common-criteria(config)# access-list 100 permit ip any host [IP of CA] loginput
TOE-common-criteria(config)# access-list 199 permit ip any host [IP of CA] loginput
To close ports that don’t need to be open and may introduce additional vulnerabilities,
implement the following acl:.
TOE-common-criteria(config)# access-list 100 deny 132 any any log-input
TOE-common-criteria(config)# access-list 199 deny 132 any any log-input
To explicitly create the default deny acl for traffic with no other match, implement the following
acl:.
TOE-common-criteria(config)# access-list 100 deny any any log-input
TOE-common-criteria(config)# access-list 199 deny any any log-input
Note: Logging of all traffic hitting the default deny acl can generate a large number of logs, and
a determination should be made whether it is necessary prior to entering this at the end of all
access lists.
To apply the acls to the interfaces:
TOE-common-criteria(config)# interface GigabitEthernet0/0
TOE-common-criteria(config-if)# ip access-group 199 in
TOE-common-criteria(config)# interface GigabitEthernet0/1
TOE-common-criteria(config-if)# ip access-group 100 in
Additional information on creation of packet filtering and VPN information flow policies is
given in Section 4.6.4 below.
The following ACL in the running-configuration can be used to block unknown protocols
(Explicitly permitting and logging specific IPv6 protocols then explicitly denying any other IPv6
packet) permit 1 <source> <destination> log
permit 2 <source> <destination> log
58
permit 3 <source> <destination> log
permit 4 <source> <destination> log
permit 5 <source> <destination> log
permit tcp <source> <destination> log
permit 7 <source> <destination> log
permit 8 <source> <destination> log
!…. continue the ACL entries to include all IPv6 protocol numbers listed in the PP.
deny ipv6 <source> <destination> log
Unevaluated Features
The administrator must be aware the following features were not part of the Common Criteria
evaluation.



Configuring Call Home for the Cisco CSR 1000V
Configuring Support for Management by REST API
Configuring Support for Remote Management by the Cisco Prime Network Services
Controller
59
7 Modes of Operation
A CSR1000V router has several modes of operation, these modes are as follows:
Booting – while booting, the routers drop all network traffic until the router image and
configuration has loaded. This mode of operation automatically progresses to the Normal mode
of operation. During booting, an administrator may press the break key on a console connection
within the first 60 seconds of startup to enter the ROM Monitor mode of operation. This Booting
mode is referred to in the IOS guidance documentation as “ROM Monitor Initialization”.
Additionally if the Router does not find a valid operating system image it will enter ROM
Monitor mode and not normal mode therefore protecting the router from booting into an insecure
state.
Normal - The IOS router image and configuration is loaded and the router is operating as
configured. It should be noted that all levels of administrative access occur in this mode and that
all router based security functions are operating. While operating the router have little interaction
with the administrator. However, the configuration of the router can have a detrimental effect on
security. Misconfiguration of the router could result in the unprotected network having access to
the internal/protected network
Following operational error, the TOE reboots (once power supply is available) and enters
booting mode. The only exception to this is if there is an error during the Power on Startup Test
(POST) during bootup, then the TOE will shutdown. If any component reports failure for the
POST, the system crashes and appropriate information is displayed on the screen, and saved in
the crashinfo file. Within the POST, self-tests for the cryptographic operations are performed.
The same cryptographic POSTs can also be run on-demand as described in section 3.1.3 , and
when the tests are run on-demand after system startup has completed (and the syslog daemon has
started), error messages will be written to the log.
All ports are blocked from moving to forwarding state during the POST. Only when all
components of all modules pass the POST is the system placed in FIPS PASS state and ports are
allowed to forward data traffic.
If any of the POST fail, the following actions should be taken:




If possible, review the crashinfo file. This will provide additional information on the cause of
the crash
Restart the TOE to perform POST and determine if normal operation can be resumed
If the problem persists, contact Cisco Technical Assistance via
http://www.cisco.com/techsupport or 1 800 553-2447
If necessary, return the TOE to Cisco under guidance of Cisco Technical Assistance.
If a software upgrade fails, the CSR1000V will display an error when an authorized
administrator tries to boot the system.
Directory an_image.bin not found
Unable to locate an_image.bin directory
60
Unable to load an_image.bin
boot: error executing "boot harddisk:an_image.bin"
autoboot: boot failed, restarting
8 Security Measures for the Operational Environment
Proper operation of the TOE requires functionality from the environment. It is the responsibility
of the authorized administrator of the TOE to ensure that the Operational Environment provides
the necessary functions, and adheres to the environment security objectives listed below. The
environment security objective identifiers map to the environment security objectives as defined
in the Security Target.
Table 7 Operational Environment Security Measures
Environment Security
Objective
Operational Environment
Security Objective Definition
Privileged
administrator
responsibility
Administrators will make sure
the TOE is configured so that
all data flows connected to the
VPN client flow through the
TOE. For more information
refer to the “Mapping Cisco
CSR 1000V Network
Interfaces to VM Network
Interfaces” section of [1]
OE.NO_TOE_BYPASS
Information cannot flow onto the
network to which the VPN client's
host is connected without passing
through the TOE.
OE.PHYSICAL
Physical security, commensurate
with the value of the TOE and the
data it contains, is provided by the
environment.
Administrators must ensure
the TOE is installed and
maintained within a secure
physical location. This can
include a secured building
with key card access or within
the physical control of an
authorized administrator in a
mobile environment.
OE.TRUSTED_CONFIG
Personnel configuring the TOE
and its operational environment
will follow the applicable
security configuration guidance.
Administrators must be
properly trained in the usage
and proper operation of the
TOE and all the provided
functionality per the
implementing organization’s
operational security policies.
These administrators must
follow the provided guidance.
9 Related Documentation
Use this document in conjunction with the IOS XE 16.3 documentation at the following location:

http://www.cisco.com/
61
Obtaining Documentation
The following sections provide sources for obtaining documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following
sites:



http://www.cisco.com
http://www-china.cisco.com
http://www-europe.cisco.com
Ordering Documentation
Cisco documentation is available in the following ways:
Registered Cisco Direct Customers can order Cisco Product documentation from the Networking
Products MarketPlace:
http://www.cisco.com/web/ordering/root/index.html
Registered Cisco.com users can order the Documentation CD-ROM through the online
Subscription Store:
http://www.cisco.com/go/subscription
Non-registered Cisco.com users can order documentation through a local account representative
by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North
America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on the World Wide Web, you can submit
technical comments electronically. Click Feedback in the toolbar and select Documentation.
After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response
card behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc., Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
62
10 Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners
can obtain documentation, troubleshooting tips, and sample configurations from online tools. For
Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides
immediate, open access to Cisco information and resources at anytime, from anywhere in the
world. This highly integrated Internet application is a powerful, easy-to-use tool for doing
business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners
streamline business processes and improve productivity. Through Cisco.com, you can find
information about Cisco and our networking solutions, services, and programs. In addition, you
can resolve technical issues with online technical support, download and test software packages,
and order Cisco learning materials and merchandise. Valuable online skill assessment, training,
and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized
information and services. Registered users can order products, check on the status of an order,
access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
http://www.cisco.com
63
Download PDF
Similar pages