Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2016 Cisco Systems, Inc. All rights reserved.
Cisco 1000V Cloud Services Router VPN Client
Security Target
Version 1.0
October 6, 2016
Cisco 1000V Cloud Services Router VPN Client Security Target
2
Table of Contents
1 SECURITY TARGET INTRODUCTION..............................................................................7
1.1 ST and TOE Reference.................................................................................................. 7
1.2 TOE Overview .............................................................................................................. 7
1.2.1 TOE Product Type..................................................................................................... 7
1.2.2 Supported non-TOE / Software/ Firmware ............................................................... 8
1.3 TOE DESCRIPTION .................................................................................................... 8
1.4 Physical Scope of the TOE............................................................................................ 9
1.5 TOE Evaluated Configuration....................................................................................... 9
1.6 Logical Scope of the TOE............................................................................................. 9
1.6.1 Cryptographic support............................................................................................. 10
1.6.2 User Data Protection ............................................................................................... 10
1.6.3 Identification and authentication............................................................................. 10
1.6.4 Security Management.............................................................................................. 10
1.6.5 Protection of the TSF .............................................................................................. 11
1.6.6 Trusted Channels..................................................................................................... 11
1.7 Excluded Functionality................................................................................................ 11
2 Conformance Claims .............................................................................................................12
2.1 Common Criteria Conformance Claim ....................................................................... 12
2.2 Protection Profile Conformance.................................................................................. 12
2.3 Protection Profile Conformance Claim Rationale....................................................... 12
2.3.1 Appropriateness....................................................................................................... 12
2.3.2 TOE Security Problem Definition Consistency ...................................................... 12
2.3.3 Statement of Security Requirements Consistency................................................... 13
3 SECURITY PROBLEM DEFINITION ................................................................................14
3.1 Assumptions................................................................................................................ 14
3.2 Threats......................................................................................................................... 14
4 SECURITY OBJECTIVES ...................................................................................................15
4.1 Security Objectives for the TOE ................................................................................. 15
4.2 Security Objectives for the Environment .................................................................... 16
5 SECURITY REQUIREMENTS............................................................................................17
5.1 Conventions................................................................................................................. 17
5.2 TOE Security Functional Requirements...................................................................... 17
5.3 SFRs Drawn from VPNv1.4........................................................................................ 18
5.3.1 Cryptographic Support (FCS) ................................................................................. 18
5.3.2 User data protection (FDP)...................................................................................... 21
5.3.3 Identification and authentication (FIA)................................................................... 21
5.3.4 Security management (FMT) .................................................................................. 22
5.3.5 Protection of the TSF (FPT).................................................................................... 23
5.3.6 Trusted Path/Channels (FTP) .................................................................................. 23
5.4 TOE SFR Dependencies Rationale for SFRs Found in VPNv1.4............................... 24
5.5 Security Assurance Requirements............................................................................... 24
5.5.1 SAR Requirements.................................................................................................. 24
5.5.2 Security Assurance Requirements Rationale .......................................................... 24
5.5.3 Assurance Measures................................................................................................ 24
Cisco 1000V Cloud Services Router VPN Client Security Target
3
6 TOE Summary Specification.................................................................................................25
6.1 TOE Security Functional Requirement Measures....................................................... 25
6.2 Key Zeroization........................................................................................................... 30
7 Annex A: References.............................................................................................................33
Cisco 1000V Cloud Services Router VPN Client Security Target
4
List of Tables
TABLE 1 ACRONYMS ......................................................................................................................................................................................... 5
TABLE 2 TERMINOLOGY................................................................................................................................................................................... 5
TABLE 3: ST AND TOE IDENTIFICATION ...................................................................................................................................................... 7
TABLE 4: IT ENVIRONMENT COMPONENTS................................................................................................................................................... 8
TABLE 5 FIPS REFERENCES...........................................................................................................................................................................10
TABLE 6: EXCLUDED FUNCTIONALITY.........................................................................................................................................................11
TABLE 7: PROTECTION PROFILES .................................................................................................................................................................12
TABLE 8 TOE ASSUMPTIONS.........................................................................................................................................................................14
TABLE 9 THREATS...........................................................................................................................................................................................14
TABLE 10 SECURITY OBJECTIVES FOR THE TOE........................................................................................................................................15
TABLE 11 SECURITY OBJECTIVES FOR THE ENVIRONMENT......................................................................................................................16
TABLE 12 SECURITY FUNCTIONAL REQUIREMENTS .................................................................................................................................17
TABLE 13: ASSURANCE MEASURES ..............................................................................................................................................................24
TABLE 14: ASSURANCE MEASURES ..............................................................................................................................................................24
TABLE 15 HOW TOE SFRS MEASURES.......................................................................................................................................................25
TABLE 16: TOE KEY ZEROIZATION..............................................................................................................................................................30
TABLE 17: REFERENCES.................................................................................................................................................................................33
List of Figures
FIGURE 1 TOE EXAMPLE DEPLOYMENT....................................................................................................................................................... 8
Cisco 1000V Cloud Services Router VPN Client Security Target
5
List of Acronyms
The following acronyms and abbreviations are common and may be used in this Security
Target:
Table 1 Acronyms
Acronyms /
Abbreviations
Definition
AES Advanced Encryption Standard
CC Common Criteria for Information Technology Security Evaluation
CEM Common Evaluation Methodology for Information Technology Security
CM Configuration Management
DRBG Deterministic Random Bit Generator
EAL Evaluation Assurance Level
EC-DH Elliptic Curve-Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
ESP Encapsulating Security Payload
GCM Galois Counter Mode
HMAC Hash Message Authentication Code
IKE Internet Key Exchange
IPsec Internet Protocol Security
IT Information Technology
OS Operating System
PP Protection Profile
PRF Pseudo-Random Functions
RFC Request For Comment
SHS Secure Hash Standard
SPD Security Policy Database
ST Security Target
TCP Transport Control Protocol
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Function
TSP TOE Security Policy
UDP User datagram protocol
VPN Virtual Private Network
Terminology
Table 2 Terminology
Term Definition
Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an
independent computing system.
Cisco 1000V Cloud Services Router VPN Client Security Target
6
DOCUMENT INTRODUCTION
Prepared By:
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
This document provides the basis for an evaluation of a specific Target of Evaluation (TOE),
the 1000V Cloud Services Router (CSR). This Security Target (ST) defines a set of
assumptions about the aspects of the environment, a list of threats that the product intends to
counter, a set of security objectives, a set of security requirements, and the IT security functions
provided by the TOE which meet the set of requirements. Administrators of the TOE will be
referred to as administrators, Authorized Administrators, TOE administrators, semi-privileged,
privileged administrators, and security administrators in this document. The Common Criteria
Functional Specification is met through the description of interfaces in this Security Target and
the parameters described within the Common Criteria Guidance Documentation as well as the
Cisco documentation for TOE.
Cisco 1000V Cloud Services Router VPN Client Security Target
7
1 SECURITY TARGET INTRODUCTION
The Security Target contains the following sections:
 Security Target Introduction [Section 1]
 Conformance Claims [Section 2]
 Security Problem Definition [Section 3]
 Security Objectives [Section 4]
 IT Security Requirements [Section 5]
 TOE Summary Specification [Section 6]
 References [Section 7]
The structure and content of this ST comply with the requirements specified in the Common
Criteria (CC), Part 1, Annex A, and Part 2.
1.1 ST and TOE Reference
This section provides information needed to identify and control this ST and its TOE.
Table 3: ST and TOE Identification
Name Description
ST Title 1000V Cloud Services Router
ST Version 1.0
Publication Date October 6, 2016
Vendor and ST Author Cisco Systems, Inc.
TOE Reference 1000V Cloud Services Router
TOE Software Version IOS XE 3.16
Keywords Data Protection, Authentication, VPN
1.2 TOE Overview
The Cisco 1000V Cloud Services Router TOE is a software-only virtual form factor router that
securely connects distributed sites within an organization. For example the Cisco 1000V Cloud
Services Router allows an organization to extend a remote branch office site to its data center.
Alternatively, for cloud service providers, it connects a tenant’s network to the organization’s
data center or headend site.
The focus of the evaluation is on the IPsec VPN component of the Cisco 1000V Cloud Services
Router. IPsec allows an organization to securely connect its sites connected over an untrusted
network by protecting communications from unauthorized disclosure or modification.
1.2.1 TOE Product Type
For purposes of this Security Target, the TOE product type is a VPN client. The VPN
component of the Cisco 1000V Cloud Services Router provides protection of data in transit
across an untrusted network by implementing IPsec to authenticate and encrypt traffic between
network nodes.
Cisco 1000V Cloud Services Router VPN Client Security Target
8
1.2.2 Supported non-TOE / Software/ Firmware
The TOE requires the following IT Environment Components when the TOE is configured in its
evaluated configuration:
Table 4: IT Environment Components
Component Required Usage/Purpose Description
VMware ESXi Yes Provides virtualization server/hypervisor on general-purpose computers.
Certification
Authority
No A Certificate Authority is used to provide valid digital certificates.
VPN Peer or
Gateway
Yes This includes any IPsec peer or VPN Gateway with which the TOE participates
in a secure IPsec session.
1.3 TOE DESCRIPTION
The TOE is the VPN component of the Cisco 1000V Cloud Services Router, version 3.16. The
TOE provides IPsec VPN tunnel to authenticate and encrypt network traffic travelling across an
unprotected public network protecting an organization’s network communication from
unauthorized disclosure or modification. The TOE allows an organization to securely connect a
remote site to a headend site.
The following figure provides a simplified visual depiction of an example TOE deployment.
The boundary is surrounded with a hashed red line.
Figure 1 TOE Example Deployment
Cisco 1000V Cloud Services Router VPN Client Security Target
9
1.4 Physical Scope of the TOE
The physical scope of the TOE is the IPsec VPN component inclusive of Cisco IOS-XE 3.16
network operating system as depicted in figure 1. Features of Cisco IOS-XE outside of IPsec
are not covered by the evaluation.
The underlying platform on which the TOE resides is the guest virtual machine and VMware
ESXi Hypervisor. The Guest VM contains the virtualized hardware environment on which the
TOE executes. The guest virtual machine, VMware ESXi Hypervisor, and physical hardware
are considered part of the IT environment.
1.5 TOE Evaluated Configuration
The TOE evaluated configuration requires the following:
 VMware ESXi 5.0, 5.1, 5.5, or 6.0 Hypervisor
 A single Guest Virtual Machine supporting:
o Single hard disk
o 8 GB virtual disk
o The following virtual CPU configurations are supported:
 1 virtual CPU, requiring 4 GB minimum of RAM
 2 virtual CPUs, requiring 4 GB minimum of RAM
 4 virtual CPUs, requiring 4 GB minimum of RAM
 8 virtual CPUs, requiring 4 GB minimum of RAM
o 2 or more virtual network interface cards
 Remote VPN peer or gateway
For the Common Criteria evaluation the TOE was tested on the following:
Platform Model Hypervisor Processor
Cisco EN120E 208 VMware ESXi 5.5 Intel Atom
Cisco EN120S M2 VMware ESXi 5.5 Intel Xeon
1.6 Logical Scope of the TOE
The TOE is comprised of several security features. Each of the security features identified
above consists of several security functionalities, as identified below.
1. Cryptographic Support
2. User Data Protection
3. Identification and Authentication
4. Security Management
5. Protection of the TSF
6. Trusted Channels
These features are described in more detail in the subsections below.
Cisco 1000V Cloud Services Router VPN Client Security Target
10
1.6.1 Cryptographic support
The TOE provides cryptography in support of:
 Symmetric cryptography for bulk AES encryption/decryption
 Diffie-Hellman key exchange
 DRBG
 Asymmetric cryptography for digital signatures (RSA/ECDSA), hashing, and HMAC
services
 Asymmetric cryptography for IKE peer authentication using X.509 digital certificates
The cryptographic algorithm implementation has been validated for CAVP conformance. See
Table 5 for algorithm certificate references).
Table 5 FIPS References
Algorithm Algorithm Cert. #
AES 3989
SHS 1/256/512 3293
HMAC SHA1 2604
RSA 2047
ECDSA 885
DRBG 1181
KBKDF 94
CVL 830, 252
1.6.2 User Data Protection
The TOE platform ensures that residual information from previously sent network packets
processed through the platform are protected from being passed into subsequent network
packets.
1.6.3 Identification and authentication
The TOE performs device-level authentication of the remote device (IPsec peers or VPN
Gateway). Device-level authentication allows the TOE to establish a secure channel with a
trusted peer. The secure channel is established only after each device authenticates the other.
Device-level authentication is performed via IKE/IPsec mutual authentication. The TOE uses
X.509v3 certificates as defined by RFC 5280 to support authentication for IPsec sessions.
1.6.4 Security Management
The TOE provides management functions to configure the security functionality provided by
the TOE.
Cisco 1000V Cloud Services Router VPN Client Security Target
11
1.6.5 Protection of the TSF
The TOE performs a suite of self-tests during initial start-up to verify correct operation of itself
and its FIPS 140-2 validated algorithms. The TOE provides for verification of TOE software
updates upon installation.
1.6.6 Trusted Channels
The TOE initiates IPsec tunnels with remote IPsec peers and VPN Gateways.
1.7 Excluded Functionality
The following functionality is excluded from the evaluation.
Table 6: Excluded Functionality
Excluded Functionality Exclusion Rationale
Non-FIPS 140-2 mode of operation on the TOE This mode of operation allows cryptographic
operations that are not FIPS-approved.
Aggressive mode for IKEv1 exchanges This mode of operation passes initiator and
responder ID in the clear and will be disabled by
configuration.
Confidentiality only ESP mode This mode of operation does not include integrity
and will be disabled by configuration.
The excluded functionality in table 6 will be disabled in the evaluated configuration. The
exclusion of this functionality does not affect conformance to the Protection Profile for IPsec
Virtual Private Network (VPN) Clients.
Cisco 1000V Cloud Services Router VPN Client Security Target
12
2 CONFORMANCE CLAIMS
2.1 Common Criteria Conformance Claim
The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Revision 4,
September 2012.
The ST is CC Part 2 extended and CC Part 3 conformant.
2.2 Protection Profile Conformance
The TOE and ST are conformant with the Protection Profile for IPsec Virtual Private Network
(VPN) Clients (VPNv1.4).
This ST is conformant to the following NIAP-approved Common Criteria validated Protection
Profile:
Table 7: Protection Profiles
Protection Profile Version Date
Protection Profile for IPsec Virtual Private Network (VPN) Clients 1.4 21 October 2013
2.3 Protection Profile Conformance Claim Rationale
2.3.1 Appropriateness
The ST provides all of the functionality at a level of security commensurate with that identified
in the U.S. Government Protection Profile:
 Protection Profile for IPsec Virtual Private Network (VPN) Clients v1.4
This ST applies the following NIAP Technical Decisions:
 TD0037: IPsec Requirement_DN Verification
 TD0097: VPN Gateway selection for FCS_IPSEC_EXT.1.14
2.3.2 TOE Security Problem Definition Consistency
The Assumptions, Threats, and Organization Security Policies included in the Security Target
represent the Assumptions, Threats, and Organization Security Policies specified in the
VPNv1.4 for which conformance is claimed verbatim. All concepts covered in the Protection
Profile Security Problem Definition are included in the Security Target Statement of Security
Objectives Consistency.
The Security Objectives included in the Security Target represent the Security Objectives
specified in the VPNv1.4 for which conformance is claimed verbatim. All concepts covered in
the Protection Profile’s Statement of Security Objectives are included in the Security Target.
Cisco 1000V Cloud Services Router VPN Client Security Target
13
2.3.3 Statement of Security Requirements Consistency
The Security Functional Requirements included in the Security Target represent the Security
Functional Requirements specified in the VPNv1.4 for which conformance is claimed verbatim.
All concepts covered in the Protection Profile’s Statement of Security Requirements are
included in this Security Target. Additionally, the Security Assurance Requirements included
in this Security Target are identical to the Security Assurance Requirements included in section
4.3 of the VPNv1.4.
Cisco 1000V Cloud Services Router VPN Client Security Target
14
3 SECURITY PROBLEM DEFINITION
This chapter identifies the following:
 Significant assumptions about the TOE’s operational environment.
 IT related threats to the organization countered by the TOE.
 Environmental threats requiring controls to provide sufficient protection.
 Organizational security policies for the TOE as appropriate.
This document identifies assumptions as A.assumption with “assumption” specifying a unique
name. Threats are identified as T.threat with “threat” specifying a unique name.
3.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
environment. These assumptions include both practical realities in the development of the TOE
security requirements and the essential environmental conditions on the use of the TOE.
Table 8 TOE Assumptions
3.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The
assumed level of expertise of the attacker for all the threats identified below is Enhanced-Basic.
Table 9 Threats
Threat Threat Definition
T.TSF_CONFIGURATION Failure to allow configuration of the TSF may prevent its users from being
able to adequately implement their particular security policy, leading to a
compromise of user information.
T.TSF_FAILURE Security mechanisms of the TOE may fail, leading to a compromise of the
TSF.
T.UNAUTHORIZED_ACCESS A user may gain unauthorized access to the TOE data. A malicious user,
process, or external IT entity may masquerade as an authorized entity in order
to gain unauthorized access to data or TOE resources. A malicious user,
process, or external IT entity may misrepresent itself as the TOE to obtain
identification and authentication data.
T.UNAUTHORIZED_UPDATE A malicious party attempts to supply the end user with an update to the
product that may compromise the security features of the TOE.
T.USER_DATA_REUSE User data may be inadvertently sent to a destination not intended by the
original sender because it is not rendered inaccessible after it is done being
used.
Assumption Assumption Definition
A.NO_TOE_BYPASS Information cannot flow onto the network to which the VPN client's host
is connected without passing through the TOE.
A.PHYSICAL Physical security, commensurate with the value of the TOE and the data
it contains, is assumed to be provided by the environment.
A.TRUSTED_CONFIG Personnel configuring the TOE and its operational environment will
follow the applicable security configuration guidance.
Cisco 1000V Cloud Services Router VPN Client Security Target
15
4 SECURITY OBJECTIVES
This Chapter identifies the security objectives of the TOE and the IT Environment. The security
objectives identify the responsibilities of the TOE and the TOE’s IT environment in meeting the
security needs.
 This document identifies objectives of the TOE as O.objective with objective specifying
a unique name. Objectives that apply to the IT environment are designated as
OE.objective with objective specifying a unique name.
4.1 Security Objectives for the TOE
The following table, Security Objectives for the TOE, identifies the security objectives of the
TOE. These security objectives reflect the stated intent to counter identified threats and/or
comply with any security policies identified. An explanation of the relationship between the
objectives and the threats/policies is provided in the rationale section of this document.
Table 10 Security Objectives for the TOE
TOE Objective TOE Security Objective Definition
O.VPN_TUNNEL The TOE will provide a network communication channel
protected by encryption that ensures that the VPN client
communicates with an authenticated VPN gateway.
O.RESIDUAL_INFORMATION_CLEARING The TOE will ensure that any data contained in a protected
resource is not available when the resource is reallocated.
O.TOE_ADMINISTRATION The TOE will provide mechanisms to allow administrators to
be able to configure the TOE.
O.TSF_SELF_TEST The TOE will provide the capability to test some subset of its
security functionality to ensure it is operating properly.
O.VERIFIABLE_UPDATES The TOE will provide the capability to help ensure that any
updates to the TOE can be verified by the administrator to be
unaltered and (optionally) from a trusted source.
Cisco 1000V Cloud Services Router VPN Client Security Target
16
4.2 Security Objectives for the Environment
All of the assumptions stated in section 3.1 are considered to be security objectives for the
environment. The following are the Protection Profile non-IT security objectives, which, in
addition to those assumptions, are to be satisfied without imposing technical requirements on
the TOE. That is, they will not require the implementation of functions in the TOE software.
Thus, they will be satisfied largely through application of procedural or administrative
measures.
Table 11 Security Objectives for the Environment
Environment Security Objective IT Environment Security Objective Definition
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 assumed to be provided by the operational
environment.
OE.TRUSTED_CONFIG Personnel configuring the TOE and its operational environment
will follow the applicable security configuration guidance.
Cisco 1000V Cloud Services Router VPN Client Security Target
17
5 SECURITY REQUIREMENTS
This section identifies the Security Functional Requirements for the TOE. The Security
Functional Requirements included in this section are derived from Part 2 of the Common
Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, dated:
September 2012 and all international interpretations.
5.1 Conventions
The CC defines operations on Security Functional Requirements: assignments, selections,
assignments within selections and refinements. This document uses the following font
conventions to identify the operations defined by the CC:
 Where operations were completed in the VPNv1.4 itself, the formatting used in the
VPNv1.4 has been retained;
 Assignment: Indicated with italicized text, which may or may not be bracketed;
 Refinement made by PP author: Indicated with bold text; may have Refinement: at the
beginning of the element for further clarification.
 Selection: Indicated with underlined text, which may or may not be bracketed;
 Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3).
Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for
TOE SFRs.
5.2 TOE Security Functional Requirements
This section identifies the Security Functional Requirements for the TOE. The TOE Security
Functional Requirements that appear in the following table are described in more detail in the
following subsections.
Table 12 Security Functional Requirements
Class Name Component
Identification
Component Name
FCS: Cryptographic support FCS_CKM.1 Cryptographic Key Generation (for asymmetric keys)
FCS_CKM_EXT.4 Cryptographic Key Zeroization
FCS_COP.1(1) Cryptographic Operation (for data
encryption/decryption)
FCS_COP.1(2) Cryptographic Operation (for cryptographic
signature)
FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing)
FCS_COP.1(4) Cryptographic Operation (for keyed-hash message
authentication)
FCS_IPSEC_EXT.1 Explicit: IPSEC
FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit
Generation)
FDP: User data protection FDP_RIP.2 Full Residual Information Protection
FIA: Identification and
authentication
FIA_PSK_EXT.1 Extended: Pre-Shared Key Composition
FIA_X509_EXT.1 Extended: X.509 Certificate Validation
FIA_X509_EXT.2 Extended: X.509 Certificate Use and Management
FMT: Security management FMT_SMF.1 Specification of Management Functions
Cisco 1000V Cloud Services Router VPN Client Security Target
18
Class Name Component
Identification
Component Name
FPT: Protection of the TSF FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Extended: Trusted Update
FTP: Trusted path/channels FTP_ITC.1 Trusted Channel
5.3 SFRs Drawn from VPNv1.4
5.3.1 Cryptographic Support (FCS)
FCS_CKM.1(1) Cryptographic Key Generation (for asymmetric keys)
5.3.1.1
FCS_CKM.1.1(1) Refinement: The TOE shall generate asymmetric cryptographic keys used
for key establishment in accordance with:
 NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography” for finite field-based key
establishment schemes;
 NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography” for elliptic curve-based key
establishment schemes and implementing “NIST curves” P-256, P-384 (as defined in
FIPS PUB 186-4, “Digital Signature Standard”)
 NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography” for RSA-based key establishment
schemes
and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of
112 bits. See NIST Special Publication 800-57, “Recommendation for Key Management” for
information about equivalent key strengths.
FCS_CKM.1(2) Cryptographic Key Generation (for asymmetric keys)
5.3.1.2
FCS_CKM.1.1(2) Refinement: The TOE shall generate asymmetric cryptographic keys used
for IKE peer authentication in accordance with a:
[
 FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA schemes;
 FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA
schemes and implementing “NIST curves” P-256, P-384.]
and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of
112 bits.
Cisco 1000V Cloud Services Router VPN Client Security Target
19
FCS_CKM_EXT.2 Cryptographic Key Storage
5.3.1.3
FCS_CKM_EXT.2.1 The TOE shall store persistent secrets and private keys when not in use in
platform-provided key storage.
FCS_CKM_EXT.4 Cryptographic Key Zeroization
5.3.1.4
FCS_CKM_EXT.4.1 The TOE shall zeroize all plaintext secret and private cryptographic keys
and CSPs when no longer required.
FCS_COP.1(1) Cryptographic Operation (for data encryption/decryption)
5.3.1.5
FCS_COP.1.1(1) Refinement: The TOE shall perform [encryption and decryption] in
accordance with a specified cryptographic algorithm AES operating in GCM and CBC mode
with cryptographic key sizes 128-bits and 256-bits that meets the following:
 FIPS PUB 197, “Advanced Encryption Standard (AES)”
 NIST SP 800-38D, NIST SP 800-38A.
FCS_COP.1(2) Cryptographic Operation (for cryptographic signature)
5.3.1.6
FCS_COP.1.1(2) Refinement: The TOE shall perform cryptographic signature services in
accordance with a specified cryptographic algorithm:
 FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA
scheme
 FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA
schemes and implementing “NIST curves” P-256, P-384
and cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112
bits.
FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing)
5.3.1.7
FCS_COP.1.1(3) Refinement: The TOE shall perform [cryptographic hashing services] in
accordance with a specified cryptographic algorithm SHA-1, SHA-256, SHA-512 and message
digest sizes 160, 256, 512 bits that meet the following: FIPS Pub 180-4, “Secure Hash
Standard.”
FCS_COP.1(4) Cryptographic Operation (for keyed-hash message authentication)
5.3.1.8
FCS_COP.1.1(4) Refinement: The TOE shall perform keyed-hash message authentication in
accordance with a specified cryptographic algorithm HMAC-[ SHA-1], key size [160- bits],
and message digest size of [160] bits that meet the following: FIPS Pub 198-1, "The Keyed-
Hash Message Authentication Code", and FIPS Pub 180-4, “Secure Hash Standard.”
Cisco 1000V Cloud Services Router VPN Client Security Target
20
FCS_IPSEC_EXT.1 Explicit: IPSEC
5.3.1.9
FCS_IPSEC_EXT.1.1 The TOE shall implement the IPsec architecture as specified in RFC
4301.
FCS_IPSEC_EXT.1.2 The TOE shall implement [tunnel mode, transport mode].
FCS_IPSEC_EXT.1.3 The TOE shall have a nominal, final entry in the SPD that matches
anything that is otherwise unmatched, and discards it.
FCS_IPSEC_EXT.1.4 The TOE shall implement the IPsec protocol ESP as defined by RFC
4303 using the cryptographic algorithms AES-GCM-128, AES-GCM-256 as specified in RFC
4106, AES-CBC-128, AES-CBC-256 (both specified by RFC 3602) together with a Secure
Hash Algorithm (SHA)-based HMAC.
FCS_IPSEC_EXT.1.5 The TOE shall implement the protocol: [IKEv1 as defined in RFCs
2407, 2408, 2409, RFC 4109, [no other RFCs for extended sequence numbers], and [no other
RFCs for hash functions]; IKEv2 as defined in RFCs 5996 (with mandatory support for NAT
traversal as specified in section 2.23), 4307, and [no other RFCs for hash functions]].
FCS_IPSEC_EXT.1.6 The TOE shall ensure the encrypted payload in the [IKEv1, IKEv2]
protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC
6379 and [no other algorithm].
FCS_IPSEC_EXT.1.7 The TOE shall ensure that IKEv1 Phase 1 exchanges use only main
mode.
FCS_IPSEC_EXT.1.8 The TOE shall ensure that [IKEv2 SA lifetimes can be configured by an
Administrator based on number of packets/number of bytes; length of time, where the time
values can be limited to: 24 hours for Phase 1 SAs and 8 hours for Phase 2 SAs]; IKEv1 SA
lifetimes can be configured by an Administrator based on number of packets/number of bytes;
length of time, where the time values can be limited to: 24 hours for Phase 1 SAs and 8 hours
for Phase 2 SAs.
FCS_IPSEC_EXT.1.9 The TOE shall generate the secret value x used in the IKE Diffie-
Hellman key exchange (“x” in gx
mod p) using the random bit generator specified in
FCS_RBG_EXT.1, and having a length of at least 320 (for DH Group 14), 256 (for DH Group
19), 256 (for DH Group 24), 384 (for DH Group 20), 424 (for DH Group 15), and 480 (bits for
DH Group 16)] bits.
FCS_IPSEC_EXT.1.10 The TOE shall generate nonces used in IKE exchanges in a manner
such that the probability that a specific nonce value will be repeated during the life a specific
IPsec SA is less than 1 in 2^[128].
FCS_IPSEC_EXT.1.11 The TOE shall ensure that all IKE protocols implement DH Groups 14
(2048-bit MODP), 19 (256-bit Random ECP), and 24 (2048-bit MODP with 256-bit POS), 20
(384-bit Random ECP), 15 (3072 bit MODP), and 16 (4096-bit MODP)].
Cisco 1000V Cloud Services Router VPN Client Security Target
21
FCS_IPSEC_EXT.1.12 The TOE shall ensure that all IKE protocols perform peer
authentication using a [RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945
and Pre-shared Keys.
FCS_IPSEC_EXT.1.13 The TOE shall support peer identifiers of the following types:
Distinguished Name (DN) and [no other reference identifier type].
FCS_IPSEC_EXT.1.14 The TOE shall be able to ensure by default that the strength of the
symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the IKEv1
Phase 1, IKEv2 IKE_SA connection is greater than or equal to the strength of the symmetric
algorithm (in terms of the number of bits in the key) negotiated to protect the IKEv1 Phase 2,
IKEv2 CHILD_SA connection.
FCS_RBG_(EXT).1 Extended: Cryptographic Operation (Random Bit Generation)
5.3.1.10
FCS_RBG_EXT.1.1 The TOE shall perform all deterministic random bit generation services in
accordance with NIST Special Publication 800-90A using CTR_DRBG (AES).
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by an entropy source that
accumulates entropy from a software-based noise source with a minimum of 256 bits of entropy
at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and
hashes that it will generate.
5.3.2 User data protection (FDP)
FDP_RIP.2 Full Residual Information Protection
5.3.2.1
FDP_RIP.2.1 The TOE Platform shall enforce that any previous information content of a
resource is made unavailable upon the allocation of the resource to all objects.
5.3.3 Identification and authentication (FIA)
FIA_PSK_EXT.1 Extended: Pre-Shared Key Composition
5.3.3.1
FIA_PSK_EXT.1.1 The TOE shall be able to use pre-shared keys for IPsec.
FIA_PSK_EXT.1.2 The TOE shall be able to accept text-based pre-shared keys that:
 are 22 characters and [any combination of alphanumeric or special characters up
to 128 bytes];
 composed of any combination of upper and lower case letters, numbers, and
special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and
“)”).
Cisco 1000V Cloud Services Router VPN Client Security Target
22
FIA_PSK_EXT.1.3 The TOE shall condition the text-based pre-shared keys by using [SHA-1]
be able to accept bit-based pre-shared keys.
FIA_X509_EXT.1 Extended: X.509 Certificates
5.3.3.2
FIA_X509_EXT.1.1 The TOE shall validate certificates in accordance with the following rules:
 Perform RFC 5280 certificate validation and certificate path validation.
 Validate the revocation status of the certificate using the Online Certificate Status
Protocol (OCSP) as specified in RFC 2560, a Certificate Revocation List (CRL) as
specified in RFC 5759.
 Validate the certificate path by ensuring the basicConstraints extension is present
and the cA flag is set to TRUE for all CA certificates.
 Validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates, integrity verification shall have the Code
Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3).
FIA_X509_EXT.1.2 The TOE shall only treat a certificate as a CA certificate if the following
is met: the basicConstraints extension is present and the cA flag is set to TRUE.
FIA_X509_EXT.2 Extended: X.509 Certificate Use and Management
5.3.3.3
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec exchanges, and no additional uses.
FIA_X509_EXT.2.2 When a connection to determine the validity of a certificate cannot be
established, the TOE shall not accept the certificate.
FIA_X509_EXT.2.3 The TOE shall not establish an SA if a certificate or certificate path is
deemed invalid.
5.3.4 Security management (FMT)
FMT_SMF.1 Specification of Management Functions
5.3.4.1
FMT_SMF.1.1 The TOE shall be capable of performing the following management functions:
 Configuration of IKE protocol version(s) used,
 Configure IKE authentication techniques used,
 Configure the cryptoperiod for the established session keys. The unit of measure
for configuring the cryptoperiod shall be no greater than an hour,
 Configure certificate revocation check,
 Specify the algorithm suites that may be proposed and accepted during the IPsec
exchanges,
 load X.509v3 certificates used by the security functions in this PP,
 configure the reference identifier for the peer,
Cisco 1000V Cloud Services Router VPN Client Security Target
23
 ability to update the TOE, and to verify the updates,
 ability to configure all security management functions identified in other sections
of this PP,
 specify VPN gateways to use for connections,
 specify client credentials to be used for connections,
 action to be taken when a connection to determine the validity of a certificate
cannot be established.
5.3.5 Protection of the TSF (FPT)
FPT_TST_EXT.1: TSF Testing
5.3.5.1
FPT_TST_EXT.1.1 The TOE shall run a suite of self tests during initial start-up (on power on)
to demonstrate the correct operation of the TSF.
FPT_TST_EXT.1.2 The TOE shall provide the capability to verify the integrity of stored TSF
executable code when it is loaded for execution through the use of the cryptographic hash
verification per FCS_COP.1(3).
FPT_TUD_(EXT).1 Extended: Trusted Update
5.3.5.2
FPT_TUD_(EXT).1.1 The TOE shall provide the ability to query the current version of the
TOE firmware/software.
FPT_TUD_(EXT).1.2 The TOE shall provide the ability to initiate updates to TOE
firmware/software.
FPT_TUD_(EXT).1.3 The TOE shall provide a means to verify firmware/software updates to
the TOE using a digital signature mechanism and [no other function] prior to installing those
updates.
5.3.6 Trusted Path/Channels (FTP)
FTP_ITC.1 Inter-TSF trusted channel
5.3.6.1
FTP_ITC.1.1 Refinement: The TOE shall use IPsec to provide a trusted communication
channel between itself and a VPN Gateway that is logically distinct from other communication
channels and provides assured identification of its end points and protection of the channel data
from disclosure and detection of modification of the channel data.
FTP_ITC.1.2 The TOE shall permit the TSF to initiate communication via the trusted channel.
FTP_ ITC.1.3 The TOE shall initiate communication via the trusted channel for all traffic
traversing that connection.
Cisco 1000V Cloud Services Router VPN Client Security Target
24
5.4 TOE SFR Dependencies Rationale for SFRs Found in VPNv1.4
The VPNv1.4 contains all the requirements claimed in this Security Target. As such the
dependencies are not applicable since the PP itself has been approved.
5.5 Security Assurance Requirements
5.5.1 SAR Requirements
The TOE assurance requirements for this ST are taken directly from the Common Criteria
Version 3.1, Revision 4. The assurance requirements are summarized in the table below.
Table 13: Assurance Measures
Assurance Class Components Components Description
Development ADV_FSP.1 Basic Functional Specification
Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative User guidance
Life-cycle support ALC_CMC.1 Labeling of the TOE
ALC_CMS.1 TOE CM coverage
Test ATE_IND.1 Independent testing - conformance
Vulnerability assessment AVA_VAN.1 Vulnerability analysis
5.5.2 Security Assurance Requirements Rationale
The Security Assurance Requirements (SARs) in this Security Target represent the SARs
identified in the VPNv1.4. As such, the VPNv1.4 SAR rationale is deemed acceptable since the
PP itself has been validated.
5.5.3 Assurance Measures
The TOE satisfies the identified assurance requirements. This section identifies the Assurance
Measures applied by Cisco to satisfy the assurance requirements. The table below lists the
details.
Table 14: Assurance Measures
Component How requirement will be met
ADV_FSP.1 The functional specification is comprised of the information contained in the AGD_OPR and
AGD_PRE documentation, coupled with the information provided in the TSS of the ST.
AGD_OPE.1 The Administrative Guide provides operational user guidance.
AGD_PRE.1 The preparative procedures describes all the steps necessary for secure installation of the TOE
and for the secure preparation of the operational environment in accordance with the security
objectives for the operational environment as described in the ST.
ALC_CMC.1
ALC_CMS.1
Cisco will provide the TOE and a reference for the TOE.
ATE_IND.1 Cisco will provide the TOE for testing.
AVA_VAN.1 Cisco will provide the TOE for testing.
Cisco 1000V Cloud Services Router VPN Client Security Target
25
6 TOE SUMMARY SPECIFICATION
6.1 TOE Security Functional Requirement Measures
Table 15 identifies and describes how the Security Functional Requirements identified in
section 5 of this ST are met by the TOE.
Table 15 How TOE SFRs Measures
TOE SFRs How the SFR is Met
Security Functional Requirements Drawn from VPNv1.4
FCS_CKM.1(1)
FCS_CKM.1(2)
The TOE implements a random number generator for Diffie-Hellman and Elliptic
curve based key establishment (conformant to NIST SP 800-56A), for RSA key
establishment schemes (conformant to NIST SP 800-56B). As a VPN client, the
TOE only acts as a session initiator for RSA-based key establishment schemes and
does not act as a recipient.
The TOE authorized administrator creates an EC or RSA public-private key pair via
the TOE's CLI and which is used to generate a Certificate Signing Request
(CSR). The authorized administrator provides the CSR to the CA for signing using a
manual enrollment method. The TOE also supports the Simple Certificate
Enrollment Protocol (SCEP) method.
FCS_CKM_EXT.2 The TOE stores all private keys in a secure directory that is not readily accessible to
administrators. All pre-shared, private, and symmetric keys are stored in encrypted
form using the TOE's AES encryption to additionally obscure access. Pre-shared
keys can be used for authenticating to a remote IPsec peer or VPN Gateway.
Symmetric keys are used for encrypting sensitive data. Private keys are the private
key in the public-private asymmetric key pairs used for digital signature and
decryption of data.
This functionality is configured on the TOE using the ‘password encryption aes’
command.
The TOE is configured to not display configured keys as part of configuration files
using the ‘hidekeys’ command.
FCS_CKM_EXT.4 The TOE meets all requirements specified in FIPS 140-2 for destruction of keys and
Critical Security Parameters (CSPs) in that none of the symmetric keys, pre-shared
keys, or private keys are stored in plaintext form. Plaintext copies of keys in volatile
memory are zeroized automatically after the session has terminated. See Table 16
for more information on the key zeroization.
FCS_COP.1(1) The TOE provides symmetric encryption and decryption capabilities using AES in
CBC and GCM mode (128, 256 bits) as described in NIST SP 800-38A and NIST
SP 800-38D.
FCS_COP.1(2) The TOE will provide cryptographic signature services using RSA with key size of
2048 and greater as specified in FIPS PUB 186-4, “Digital Signature Standard”. In
addition, the TOE will provide cryptographic signature services using ECDSA with
key size of 256 and greater as specified in FIPS PUB 186-4, “Digital Signature
Standard”.
FCS_COP.1(3) The TOE provides cryptographic hashing services using SHA-1, SHA-256, and
SHA-512 as specified in FIPS Pub 180-4 “Secure Hash Standard.”
FCS_COP.1(4) The TOE provides keyed-hashing message authentication services using HMAC-
SHA-1 with a key size and message digest size of 160 bits as specified in FIPS Pub
198-1,"The Keyed-Hash Message Authentication Code,” and FIPS 180-4, “Secure
Hash Standard.” The block size produced for the HMAC-SHA1 is 160 bits.
Cisco 1000V Cloud Services Router VPN Client Security Target
26
TOE SFRs How the SFR is Met
FCS_IPSEC_EXT.1 The IPsec implementation provides both VPN peer-to-peer and TOE to VPN
Gateway in both tunnel and transport mode. The VPN peer-to-peer tunnel allows
for example the TOE and another VPN client to establish an IPsec tunnel to secure
the passing of user data. The TOE to VPN Gateway configuration would be where
the TOE connects into a remote VPN Gateway in order to gain access to an
authorized private network. Authenticating with the TOE would give the VPN
client a secure IPsec tunnel to connect over the internet into their private network.
In addition to tunnel mode, which is the default IPsec mode, the TOE also supports
transport mode, allowing for only the payload of the packet to be encrypted. If
tunnel mode is explicitly specified, the router will request tunnel mode and will
accept only tunnel mode.
The TOE implements IPsec to provide both certificates and pre-shared key-based
authentication and encryption services to prevent unauthorized viewing or
modification of data as it travels over the external network. When certificates are
used for authentication, the distinguished name (DN) is verified to ensure the
certificate is valid and is from a valid entity. The DN naming attributes in the
certificate is compared with the expected DN naming attributes and deemed valid if
the attribute types are the same and the values are the same and as expected.
Both OCSP and CRL are configurable and may be used for certificate revocation.
Checking is also done for the basicConstraints extension and the cA flag to
determine whether they are present and set to TRUE. If they are not, the certificate is
not accepted.
If pre-shared key authentication is used, pre-shared keys can be configured using the
‘crypto isakmp key’ key command. If the TOE and peer successfully authenticate
with a pre-shared key IKE Phase 1 authentication will succeed. Otherwise it will
fail if the pre-shared keys do not match.
The TOE implementation of the IPsec standard (in accordance with the RFCs noted
in the SFR) uses the Encapsulating Security Payload (ESP) protocol to provide
authentication, encryption, and anti-replay services. IPsec Internet Key Exchange,
also called ISAKMP, is the negotiation protocol that lets two peers agree on how to
build an IPsec Security Association (SA). The IKE protocols implement Peer
Authentication using the RSA, ECDSA algorithm with X.509v3 certificates or
preshared keys. IKE separates negotiation into two phases: phase 1 and phase 2.
Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages
using the configured isakmp policy. The key negotiated in phase 1 enables IKE
peers to communicate securely in phase 2. During Phase 2, IKE establishes the
IPsec SA using the configured IPsec transform-set. IKE maintains a trusted channel,
referred to as a Security Association (SA), between IPsec peers that is also used to
manage IPsec connections, including:
 The negotiation of mutually acceptable IPsec options between peers
(including peer authentication parameters, either signature based or pre-
shared key based),
 The establishment of additional Security Associations to protect packets
flows using Encapsulating Security Payload (ESP), and
 The agreement of secure bulk data encryption AES keys for use with ESP.
After the two peers agree upon a policy, the security parameters of the policy are
identified by an SA established at each peer, and these IKE SAs apply to all
subsequent IKE traffic during the negotiation.
The TOE supports both IKEv1 and IKEv2 session establishment. As part of this
support, the TOE can be configured to not support aggressive mode for IKEv1
exchanges and to only use main mode using the ‘crypto isakmp aggressive-mode
Cisco 1000V Cloud Services Router VPN Client Security Target
27
TOE SFRs How the SFR is Met
disable’ command.
The TOE can be configured to not allow “confidentiality only” ESP mode by
ensuring the IKE Policies configured include ESP-encryption.
The TOE supports configuration lifetimes of both Phase 1 SAs and Phase 2 SAs
using “lifetime” command. The default time value for Phase 1 SAs is 24 hours. The
default time value for Phase 2 SAs is 1 hour, but it is configurable to 8 hours.
The TOE supports configuring the maximum amount of traffic that is allowed to
flow for a given IPsec SA using the following command, ‘crypto ipsec security-
association lifetime’. The default amount is 2560KB, which is the minimum
configurable value. The maximum configurable value is 4GB.
The TOE provides AES-CBC-128, and AES-CBC-256 for encrypting the IKEv1
and IKEv2 payloads. The administrator is instructed in the AGD to ensure that the
size of key used for ESP must be less than or equal to the key size used to protect the
IKE payload.
The TOE supports Diffie-Hellman Group 14 (2048-bit keys), 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) in support of IKE Key Establishment
negotiated in phase 1. These keys are generated using the AES-CTR Deterministic
Random Bit Generator (DRBG), as specified in SP 800-90, and the following
corresponding key sizes (in bits) are used: 320 (for DH Group 14), 256 (for DH
Group 19), 256 (for DH Group 24), 384 (for DH Group 20), 424 (for DH Group 15),
and 480 (bits for DH Group 16) bits. The administrator is instructed in the AGD to
select a supported DH group.
The TOE generates the secret value 'x' used in the IKEv2 Diffie-Hellman key
exchange ('x' in gx
mod p) using the NIST approved DRBG specified in
FCS_RBG_EXT.1 and having possible lengths of 256, 320, 384, 424, or 480 bits.
When a random number is needed for a nonce, the probability that a specific nonce
value will be repeated during the life a specific IPsec SA is less than 1 in 2128
. The
nonce is likewise generated using the AES-CTR DRBG.
IPsec provides secure tunnels between two peers, such as two routers and remote
VPN clients. An authorized administrator defines which packets are considered
sensitive and should be sent through these secure 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 or between the TOE and remote VPN client. The SAs define the protocols and
algorithms to be applied to sensitive packets and specify the keying material to be
used. SAs are unidirectional and are established per security protocol (AH or ESP).
In the evaluated configuration only ESP will be configured for use.
A crypto map (the Security Policy Definition) 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 (acl) specified
in that entry. 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 ipsecisakmp, IPsec is triggered. The traffic matching the permit
acls 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. The TOE
Cisco 1000V Cloud Services Router VPN Client Security Target
28
TOE SFRs How the SFR is Met
implementation of the IPsec standard (in accordance with the RFCs noted in the
SFR and using cryptographic algorithms AES-GCM-128, AES-GCM-256, AES-
CBC-128 and AES-CBC-256 together with HMAC-SHA1) uses the
Encapsulating Security Payload (ESP) protocol to provide authentication,
encryption and anti-replay services.
If there is no SA that the IPsec can use to protect this traffic to the peer, IPsec uses
IKE to negotiate with the remote peer to set up the necessary IPsec SAs on behalf of
the 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.
FCS_RBG_EXT.1 The TOE implements a NIST-approved AES-CTR Deterministic Random Bit
Generator (DRBG), as specified in SP 800-90.
FDP_RIP.2 The TOE Platform, specifically the VMXNET3 Poll-Mode Driver (PMD), handles
all the packet buffer memory allocation and it is solely responsible to free that
memory when not needed.
FIA_PSK_EXT.1 Through the implementation of the CLI, the TOE supports use of IKEv1 (ISAKMP)
and IKEv2 pre-shared keys for authentication of IPsec tunnels. Preshared keys can
be entered as ASCII character strings or HEX values. The TOE supports keys that
are from 22 characters in length up to 128 bytes in length. The data that is input is
conditioned by the cryptographic module prior to use via SHA-1. The default SHA-
1 algorithm can be changed through the crypto isakmp policy configuration and
setting the hash algorithm.
FIA_X509_EXT.1
FIA_X509_EXT.2
The TOE uses X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec connections. Public key infrastructure (PKI) credentials,
such as Rivest, Shamir, and Adelman (RSA) keys and certificates can be stored in a
specific location on the router, such as NVRAM and flash memory. The TOE
maintains the key pair and associates it with the X.509.v3 certificate used for IPsec.
The certificates themselves provide protection in that they are digitally signed. If a
certificate is modified in any way, it would be invalidated as the digital signature
verification process would reveal the certificate was tampered with. The validity of
the certificate and the certificate chain is verified by the TOE. The physical security
provided by the environment (A.Physical) protects the TOE and the certificates from
being tampered with or deleted. In addition, the TOE identification and
authentication security functions protect an unauthorized user from gaining access to
the TOE. USB tokens provide for secure configuration distribution of the digital
certificates and private keys. RSA operations such as on-token key generation,
signing, and authentication, and the storage of IPsec credentials for deployment can
be implemented using the USB tokens. Both OCSP and CRL are configurable and
may be used for certificate revocation. Checking is also done for the
basicConstraints extension and the cA flag to determine whether they are present
and set to TRUE. If they are not, the certificate is not accepted. Certificates used for
trusted updates and integrity verification will have the code signing purpose object
identifier (id-kp 3 with OID 1.3.6.1.5.5.7.3.3).
The TOE uses X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec connections. The certificates themselves provide protection
in that they are digitally signed. When a connection to determine the validity of a
certificate cannot be established, then the TOE will reject the certificate.
FMT_SMF.1 The TOE provides all the capabilities necessary to securely manage the TOE. The
administrative user can connect to the TOE using the CLI to perform these functions
via IPsec, SSH, a terminal server, or at the local console. Refer to the Guidance
documentation for configuration syntax, commands, and information related to each
of these functions. All of these functions can be performed via the CLI either
locally or remotely.
Cisco 1000V Cloud Services Router VPN Client Security Target
29
TOE SFRs How the SFR is Met
The specific management capabilities available from the TOE include:
 Configuration of IKE protocol version(s) used,
 Configure IKE authentication techniques used,
 Configure the session key lifetimes of no greater than an hour,
 Configure certificate revocation check,
 Specify the algorithm suites that may be proposed and accepted during the
IPsec exchanges,
 load X.509v3 certificates used by the security functions in this ST,
 ability to update the TOE, and to verify the updates,
 ability to configure all security management functions identified in other
sections of this ST,
 specify VPN gateways to use for connections,
 specify client credentials to be used for connections,
 accept or deny the validity of the certificate.
The TOE provides the ability for Authorized Administrators to configure the VPN
gateways the VPN client will connect to. The client credentials can be a client
X.509 certificate and/or pre-shared key that are used for authentication to the VPN
Gateway.
FPT_TST_EXT.1 The TOE runs a suite of self-tests during initial start-up to verify correct operation of
cryptographic modules. If any of the tests fail, the Authorized Administrator will
have to log into the CLI to determine which test failed and why. If the tests pass
successfully the POST event logs will show successful for each test. During the
system boot process (power on or reboot), all the Power on Startup Test (POST)
components for all the cryptographic modules perform the POST for the software
component. These tests include:
 AES Known Answer Test - For the encrypt test, a known key is used to
encrypt a known plain text value resulting in an encrypted value. This
encrypted value is compared to a known encrypted value to ensure that the
encrypt operation is working correctly. The decrypt test is just the opposite.
In this test a known key is used to decrypt a known encrypted value. The
resulting plaintext value is compared to a known plaintext value to ensure
that the decrypt operation is working correctly.
 HMAC Known Answer Test - For each of the hash values listed, the
HMAC implementation is fed known plaintext data and a known key.
These values are used to generate a MAC. This MAC is compared to a
known MAC to verify that the HMAC and hash operations are operating
correctly.
 DRBG Known Answer Test - For this test, known seed values are provided
to the DRBG implementation. The DRBG uses these values to generate
random bits. These random bits are compared to known random bits to
ensure that the DRBG is operating correctly.
 DRBG KAT - For this test, known seed values are provided to the DRBG
implementation. The DRBG uses these values to generate random bits.
These random bits are compared to known random bits to ensure that the
DRBG is operating correctly.
 SHA-1/256/512 Known Answer Test – For each of the values listed, the
SHA implementation is fed known data and key. These values are used to
generate a hash. This hash is compared to a known value to verify they
match and the hash operations are operating correctly.
 HMAC (HMAC-SHA-1/256/512) KATs - For each of the hash values
listed, the HMAC implementation is fed known plaintext data and a known
key. These values are used to generate a MAC. This MAC is compared to a
known MAC to verify that the HMAC and hash operations are operating
Cisco 1000V Cloud Services Router VPN Client Security Target
30
TOE SFRs How the SFR is Met
correctly.
 RSA Signature Known Answer Test (both signature/verification) - This test
takes a known plaintext value and Private/Public key pair and used the
public key to encrypt the data. This value is compared to a known
encrypted value to verify that encrypt operation is working properly. The
encrypted data is then decrypted using the private key. This value is
compared to the original plaintext value to ensure the decrypt operation is
working properly.
The TOE verifies automatically whenever the system image is loaded and confirms
through use of cryptographic hash verification that the image file that’s about to be
loaded was properly maintained its integrity.
These tests are sufficient to verify that the correct version of the TOE software is
running as well as that the cryptographic operations are all performing as expected.
FPT_TUD_EXT.1 The TOE has specific versions that can be queried by an administrator. When
updates are made available by Cisco, an administrator can obtain and install those
updates. The updates can be downloaded from the Cisco.com web site. Authorized
Administrators can download the Common Criteria evaluated software image file
from Cisco.com onto a trusted computer system for usage in the trusted update
functionality. Software images are available from Cisco.com at the following:
http://www.cisco.com/cisco/software/navigator.html
When a replacement image is installed on the TOE, the digital signature will be
validated and the image will be successfully installed. When an invalid image is
attempted to be installed, the administrator, after loading the image onto the device,
needs to perform a verify operation to confirm if it is valid. The TOE will identify if
the image is valid or not, and then the administrator will manually reject a bad image
and does not proceed with the installation.
The certificate issued to the TOE used for digital signature verification needs to be
issued from a trusted external trusted Certification Authority such as ex. Verisign or
Entrust or must be from a trusted internal Certification Authority from within the
TOE administrator's company or a self-signed certificate generated on the TOE
itself.
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.
FTP_ITC.1 The TOE implements IPsec to protect communications with peer devices.
FCS_IPSEC_EXT.1 describes the cryptographic protocol implementation details.
6.2 Key Zeroization
The following table describes the key zeroization of plaintext copies of keys in volatile memory
referenced by FCS_CKM_EXT.4 provided by the TOE.
Table 16: TOE Key Zeroization
Name Description Zeroization
Cisco 1000V Cloud Services Router VPN Client Security Target
31
Name Description Zeroization
Diffie-Hellman
Shared Secret
Shared secret generated by the Diffie-Hellman Key exchange Automatically after
session is terminated
Overwrtten with: 0x00
Diffie Hellman
private exponent
The private exponent used in Diffie-Hellman (DH) exchange.
Generate by the module. Zeroized after DH shared secret has
been generated.
Automatically after shared
secret generated.
Overwrtten with: 0x00
skeyid Value derived from the shared secret within
IKE exchange. Zeroized when IKE session is terminated.
Automatically after IKE
session terminated.
Overwrtten with: 0x00
skeyid_d The IKE key derivation key for non
ISAKMP security associations.
Automatically after IKE
session terminated.
Overwrtten with: 0x00
IKE session
encrypt key
The IKE session encrypt key. Generate by the module Automatically after IKE
session terminated.
Overwrtten with: 0x00
IKE session
authentication
key
The IKE session authentication key. Generate by the module. Automatically after IKE
session terminated.
Overwrtten with: 0x00
ISAKMP
preshared
The key used to generate IKE skeyid during preshared-key
authentication. It is entered by the Crypto Officer. “no crypto
isakmp key” command zeroizes it. This key can have two forms
based on whether the key is related to the hostname or the IP
address.
Zeroized using the following
command:
# no crypto isakmp key
Overwrtten with: 0x0d
IKE RSA Private
Key
RSA private key for IKE authentication. Generated or entered
like any RSA key, set as IKE RSA Authentication Key with the
“crypto keyring” or “ca trust-point” command.
Zeroized using the following
command:
# crypto key zeroize rsa
Overwrtten with: 0x0d
IKE EC Private
Key
EC private key for IKE authentication. Generated using crypto
key generate ec command
Zeroized using the following
command:
# crypto key zeroize ec
Overwrtten with: 0x0d
IPsec encryption
key
The IPSec encryption key. Generate by the module. Zeroized
when IPSec session is terminated.
Automatically when IPsec
session terminated.
Overwrtten with: 0x00
IPsec
authentication
key
The IPSec authentication key. Generate by the module. The
zeroization is the same as above.
Automatically when IPsec
session terminated.
Cisco 1000V Cloud Services Router VPN Client Security Target
32
Name Description Zeroization
Overwrtten with: 0x00
Cisco 1000V Cloud Services Router VPN Client Security Target
33
7 ANNEX A: REFERENCES
The following documentation was used to prepare this ST:
Table 17: References
Identifier Description
[CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and
general model, dated September 2012, version 3.1, Revision 4, CCMB-20012-09-001
[CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security
functional components, dated September 2012, version 3.1, Revision 4, CCMB-2012-09-002
[CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security
assurance components, dated September 2012, version 3.1, Revision 4, CCMB-20012-09-003
[CEM] Common Methodology for Information Technology Security Evaluation – Evaluation
Methodology, dated September 2012, version 3.1, Revision 4, CCMB-2012-09-004
[VPNv1.4] Protection Profile for IPsec Virtual Private Network (VPN) Clients, 1.4, 12 October 2013