Protection Profile for Network Devices Information Assurance Directorate 08 June 2012

Protection Profile for Network Devices
Information Assurance Directorate
08 June 2012
Version 1.1
Table of Contents
1
INTRODUCTION ................................................................................................................... 1
1.1
2
2.1
2.2
2.3
2.4
2.5
2.6
3
Communications with the TOE ........................................................................................ 2
Malicious “Updates” ........................................................................................................ 3
Undetected System Activity ............................................................................................. 3
Accessing the TOE ........................................................................................................... 4
User Data Disclosure ........................................................................................................ 5
TSF Failure....................................................................................................................... 5
SECURITY OBJECTIVES ..................................................................................................... 6
3.1
3.2
3.3
3.4
3.5
3.6
4
Compliant Targets of Evaluation ..................................................................................... 1
SECURITY PROBLEM DESCRIPTION............................................................................... 2
Protected Communications .............................................................................................. 6
Verifiable Updates............................................................................................................ 7
System Monitoring ........................................................................................................... 7
TOE Administration ......................................................................................................... 8
Residual Information Clearing ......................................................................................... 8
TSF Self Test .................................................................................................................... 8
SECURITY REQUIREMENTS ............................................................................................. 9
4.1 Conventions...................................................................................................................... 9
4.2 TOE Security Functional Requirements .......................................................................... 9
4.2.1
Security Audit (FAU) ........................................................................................... 11
4.2.2
Cryptographic Support (FCS) ............................................................................... 14
4.2.3
User Data Protection (FDP) .................................................................................. 20
4.2.4
Identification and Authentication (FIA) ............................................................... 21
4.2.5
Security Management (FMT) ............................................................................... 23
4.2.6
Protection of the TSF (FPT) ................................................................................. 26
4.2.7
TOE Access (FTA) ............................................................................................... 28
4.2.8
Trusted Path/Channels (FTP)................................................................................ 30
4.3 Security Assurance Requirements .................................................................................. 33
4.3.1
Class ADV: Development..................................................................................... 34
4.3.2
Class AGD: Guidance Documents....................................................................... 35
4.3.3
Class ATE: Tests.................................................................................................. 38
4.3.4
Class AVA: Vulnerability Assessment ................................................................ 39
4.3.5
Class ALC: Life-cycle Support ............................................................................ 40
RATIONALE ................................................................................................................................. 43
Annex A: Supporting Tables ......................................................................................................... 43
Assumptions.............................................................................................................................. 43
Threats....................................................................................................................................... 43
Organizational Security Policies ............................................................................................... 44
Security Objectives for the TOE ............................................................................................... 44
Annex B: NIST SP 800-53/CNSS 1253 Mapping ......................................................................... 46
Annex C: Additional Requirements ............................................................................................... 48
Annex D: Entropy Documentation and Assessment ...................................................................... 58
ii
List of Tables
Table 1: TOE Security Functional Requirements and Auditable Events ..................................... 09
Table 2: TOE Security Assurance Requirements ......................................................................... 33
Table 3: TOE Assumptions ........................................................................................................... 43
Table 4: Threats ............................................................................................................................ 43
Table 5: Organizational Security Policies..................................................................................... 44
Table 6: Security Objectives for the TOE..................................................................................... 44
Table 7: Security Objectives for the Operational Environment.................................................... 44
Revision History
Version
1.0
1.1
Date
10 December 2010
24 February 2012
Description
Initial release
Updated with comments from community review and application of
product evaluations
iii
1
INTRODUCTION
This Protection Profile (PP), describing security requirements for a Network Device (defined to be an
infrastructure device that can be connected to a network), is intended to provide a minimal,
baseline set of requirements that are targeted at mitigating well defined and described threats. It
represents an evolution of “traditional” Protection Profiles and the associated evaluation of the
requirements contained within the document. This introduction will describe the features of a
compliant TOE, and will also discuss the evolutionary aspects of the PP as a guide to readers of the
document.
1.1 Compliant Targets of Evaluation
This is a Protection Profile (PP) for a network device. A network device in the context of this PP is a
device composed of hardware and software that is connected to the network and has an
infrastructure role in the overall enterprise. Examples of a “network device” that should claim
compliance to this PP include routers, firewalls, IDSs, audit servers, and switches that have Layer 3
functionality. Examples of devices that connect to a network but are not suitable for evaluation
against this PP include mobile devices (“smart phones”), end-user workstations, SQL servers, web
servers, application servers, and database servers.
While the functionality that the TOE is obligated to implement (in response to the described threat
environment) is discussed in detail in later sections, it is useful to give a brief description here.
Compliant TOEs will provide security functionality that addresses threats to the TOE and
implements policies that are imposed by law or regulation. Compliant TOEs must protect
communications to and between elements of a distributed TOE (e.g., between a network IDS sensor
and the centralized IDS manager) or instantiations of the TOE in a single enterprise (e.g., between
routers). The TOE must offer identification and authentication services that support the
composition of moderate complex passwords or passphrases, and make these services available
locally (that is, a local logon) as well as remotely (remote login). The TOE must also offer auditing of
a set of events that are associated with security-relevant activity on the TOE, although these events
will be stored on a device that is distinct from the TOE. The TOE must offer some protection for
common network denial of service attacks and must also provide the ability to verify the source of
updates to the TOE.
While the protocols required by this PP make use of certificates, this version of the PP does not levy
requirements on the certificate infrastructure (for example, using OCSP to verify a certificate's
validity). Such requirements will be included in future versions of this document.
It is intended that the set of requirements in this PP is limited in scope in order to promote quicker,
less costly evaluations that provide some value to end users. STs that include a large amount of
additional functionality (and requirements) are discouraged. Future modules will be used to specify
sets of additional functionality (e.g., Firewalls, VPNs), which can then be used by ST writers looking
to specify additional functionality.
1
2 SECURITY PROBLEM DESCRIPTION
As detailed in the previous section, the security problem to be addressed by compliant TOEs is
described by threats and policies that are common to network devices, as opposed to those that
might be targeted at the specific functionality of a specific type of network device. Annex A:
Supporting Tables presents the Security Problem Description (SPD) in a more “traditional” form.
The following sections detail the problems that compliant TOEs will address; references to the
“traditional” statements in Annex A are included.
2.1
Communications with the TOE
Network devices communicate with other network devices, as well as administrators, over the
network. The endpoints of the communication can be both geographically and logically distant from
the TOE, and pass through a variety of other systems. These intermediate systems may be under
the control of the adversary, and offer an opportunity for communications with the TOE to be
compromised. While these communications fall into three distinct categories (the TOE
communicating with a remote administrator; the TOE communicating in a distributed processing
environment with another instance or instances of itself; and the TOE communicating with another
IT entity that is not another instance of the TOE (e.g., an NTP server or a peer router)), the threats
to the communication between these endpoints are the same.
Plaintext communication with the TOE may allow critical data (such as passwords, configuration
settings, and routing updates) to be read and/or manipulated directly by intermediate systems,
leading to a compromise of the TOE. Several protocols can be used to provide protection; however,
each of these protocols have myriad options that can be implemented and still have the overall
protocol implementation remain compliant to the protocol specification listed in the RFC. Some of
these options can have negative impacts on the security of the connection. For instance, using a
weak encryption algorithm (even one that is allowed by the RFC, such as DES) can allow an
adversary to read and even manipulate the data on the encrypted channel, thus circumventing
countermeasures in place to prevent such attacks. Further, if the protocol is implemented with
little-used or non-standard options, it may be compliant with the protocol specification but will not
be able to interact with other, diverse equipment that is typically found in large enterprises.
Even though the communication path is protected, there is a possibility that the external entity (be
it a remote administrator, another instance of the distributed TOE, or a trusted IT entity such as a
peer router) could be duped into thinking that a malicious third-party user or system is the TOE. For
instance, a middleman could intercept a connection request to the TOE, and respond to the
external entity as if it were the TOE. In a similar manner, the TOE could also be duped into thinking
that it is establishing communications with a legitimate remote entity when in fact it is not. An
attacker could also mount a malicious man-in-the-middle-type of attack, in which an intermediate
system is compromised, and the traffic is proxied, examined, and modified by this system. This
attack can even be mounted via encrypted communication channels if appropriate
2
countermeasures are not applied. These attacks are, in part, enabled by a malicious attacker
capturing network traffic (for instance, an authentication session) and “playing back” that traffic in
order to fool an endpoint into thinking it was communicating with a legitimate remote entity.
[T.UNAUTHORIZED_ACCESS]
2.2
Malicious “Updates”
Since the most common attack vector used involves attacking unpatched versions of software
containing well-known flaws, updating network device firmware is necessary to ensure that
changes to threat environment are addressed. Timely application of patches ensures that the
system is a “hard target”, thus increasing the likelihood that product will be able to maintain and
enforce its security policy. However, the updates to be applied to the product must be trustable in
some manner; otherwise, an attacker can write their own “update” that instead contains malicious
code of their choosing, such as a rootkit, bot, or other malware. Once this “update” is installed, the
attacker then has control of the system and all of its data.
Methods of countering this threat typically involve hashes of the updates, and potentially
cryptographic operations (e.g., digital signatures) on those hashes as well. However, the validity of
these methods introduces additional threats. For instance, a weak hash function could result in the
attacker being able to modify the legitimate update in such a way that the hash remained
unchanged. For cryptographic signature schemes, there are dependencies on
1) the strength of the cryptographic algorithm used to provide the signature, and
2) the ability of the end user to verify the signature (which typically involves checking a
hierarchy of digital signatures back to a root of trust (a certificate authority)).
If a cryptographic signature scheme is weak, then it may be compromised by an attacker and the
end user will install a malicious update, thinking that it is legitimate. Similarly, if the root of trust
can be compromised, then a strong digital signature algorithm will not stop the malicious update
from being installed (the attacker will just create their own signature on the update using the
compromised root of trust, and the malicious update will then be installed without detection).
[T.UNAUTHORIZED_UPDATE]
2.3
Undetected System Activity
While several threats are directed at specific capabilities of the TOE, there is also the threat that
activity that could indicate an impending or on-going security compromise could go undetected.
Administrators can unintentionally perform actions on the TOE that compromise the security being
provided by the TOE; for instance, a mis-configuration of security parameters. Processing
performed in response to user data (for example, the establishment of a secure communications
session, cryptographic processing associated with a protected session) may give indications of a
3
failure or compromise of a TOE security mechanism (e.g., establishment of a session with an IT
entity when no such sessions should be taking place). When indications of activity that may impact
the security of the TOE are not generated and monitored, it is possible for harmful activity to take
place on the TOE without responsible officials being aware and able to correct the problem.
Further, if no data are kept or records generated, reconstruction of the TOE and the ability to
understand the extent of any compromise could be negatively affected.
While this PP requires that the TOE generates the audit data, these data are not required to be
stored on the TOE, but rather sent to a trusted external IT entity (e.g., a syslog server). These data
may be read or altered by an intervening system, thus potentially masking indicators of suspicious
activity. It may also be the case that the TOE could lose connectivity to the external IT entity,
meaning that the audit information could not be sent to the repository.
[T.ADMIN_ERROR, T.UNDETECTED_ACTIONS, T.UNAUTHORIZED_ACCESS]
2.4
Accessing the TOE
In addition to the threats discussed in Section 2.1 dealing with the TOE communicating with various
external parties that focus on the communications themselves, there are also threats that arise
from attempts to access the TOE, or the means by which these access attempts are accomplished.
For example, if the TOE does not discriminate between administrative users that are allowed to
access the TOE interactively (through a locally connected console, or with a session-oriented
protocol such as SSH) and an administrative user with no authority to use the TOE in this manner,
the configuration of the TOE cannot be trusted. Assuming that there is this distinction, there is still
the threat that one of the allowed accounts may be compromised and used by an attacker that
does not otherwise have access to the TOE.
One vector for such an attack is the use of poor passwords by authorized administrators of the TOE.
Passwords that are too short, are easily-guessed dictionary words, or are not changed very often,
are susceptible to a brute force attack. Additionally, if the password is plainly visible for a period of
time (such as when a legitimate user is typing it in during logon) then it might be obtained by an
observer and used to illegitimately access the system.
Once a legitimate administrative user is logged on, there still are a number of threats that need to
be considered. During the password change process, if the TOE does not verify that it is the
administrative user associated with the account changing the password, then anyone can change
the password on a legitimate account and take that account over. If an administrative user walks
away from a logged-in session, then another person with no access to the device could sit down and
illegitimately start accessing the TOE.
[T.UNAUTHORIZED_ACCESS]
4
2.5
User Data Disclosure
While most of the threats contained in this PP deal with TSF and administrative data, there is also a
threat against user data that all network devices should mitigate. Data traversing the TOE could
inadvertently be sent to a different user; since these data may be sensitive, this may cause a
compromise that is unacceptable. The specific threat that must be addressed concerns user data
that is retained by the TOE in the course of processing network traffic that could be inadvertently
re-used in sending network traffic to a user other than that intended by the sender of the original
network traffic.
[T.USER_DATA_REUSE]
2.6
TSF Failure
Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g.,
memory management, privileged modes of process execution) to more complex sets of
mechanisms. Failure of the primitive mechanisms could lead to a compromise in more complex
mechanisms, resulting in a compromise of the TSF.
[T.TSF_FAILURE]
5
3
SECURITY OBJECTIVES
Compliant TOEs will provide security functionality that address threats to the TOE and implement
policies that are imposed by law or regulation. The following sections provide a description of this
functionality in light of the threats previously discussed that motivate its inclusion in compliant
TOEs. The security functionality provided includes protected communications to and between
elements of the TOE; administrative access to the TOE and its configuration capabilities; system
monitoring for detection of security relevant events; and the ability to verify the source of updates
to the TOE.
3.1
Protected Communications
To address the issues concerning transmitting sensitive data to and from the TOE described in
Section 2.1, “Communications with the TOE”, compliant TOEs will provide encryption for these
communication paths between themselves and the endpoint. These channels are implemented
using one (or more) of three standard protocols: IPsec, TLS/HTTPS, and SSH. These protocols are
specified by RFCs that offer a variety of implementation choices. Requirements have been imposed
on some of these choices (particularly those for cryptographic primitives) to provide interoperability
and resistance to cryptographic attack. While compliant TOEs must support all of the choices
specified in the ST, they may support additional algorithms and protocols. If such additional
mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact
that they are not evaluated.
In addition to providing protection from disclosure (and detection of modification) for the
communications, each of the protocols described in this document (IPsec, SSH, and TLS/HTTPS)
offer two-way authentication of each endpoint in a cryptographically secure manner, meaning that
even if there was a malicious attacker between the two endpoints, any attempt to represent
themselves to either endpoint of the communications path as the other communicating party
would be detected. The requirements on each protocol, in addition to the structure of the
protocols themselves, provide protection against replay attacks such as those described in Section
2.1, usually by including a unique value in each communication so that replay of that
communication can be detected.
(FCS_CKM.1, FCS_CKM_EXT.4, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4),
FCS_RBG_EXT.1, FPT_SKP_EXT.1, FTP_ITC.1, FTP_TRP.1, (FCS_IPSEC_EXT.1, FCS_SSH_EXT.1,
FCS_TLS_EXT.1, FCS_HTTPS_EXT.1), (FPT_ITT.1(1), FPT_ITT.1(2)))1
1
The ST author should adjust the list of components that support FTP_ITC.1 and FTP_TRP.1 depending on which
are included from Appendix C. Similarly, the FPT_ITT iterations are only applicable if the TOE is distributed. If
these components are not included in the ST from Appendix C of this PP, then the ST author should remove them
from the list above.
6
3.2
Verifiable Updates
As outlined in Section 2.2, “Malicious Updates”, failure by the Security Administrator to verify that
updates to the system can be trusted may lead to compromise of the entire system. A first step in
establishing trust in the update is to publish a hash of the update that can be verified by the System
Administrator prior to installing the update. In this way, the Security Administrator can download
the update, compute the hash, and compare it to the published hash. While this establishes that
the update downloaded is the one associated with the published hash, it does not indicate if the
source of the update/hash combination has been compromised or can't be trusted. So, there
remains a threat to the system. To establish trust in the source of the updates, the system can
provide cryptographic mechanisms and procedures to procure the update, check the update
cryptographically through the TOE-provided digital signature mechanism, and install the update on
the system. While there is no requirement that this process be completely automated,
administrative guidance documentation will detail any procedures that must be performed
manually, as well as the manner in which the administrator ensures that the signature on the
update is valid.
(FPT_TUD_EXT.1, FCS_COP.1(2), FCS_COP.1(3))
3.3
System Monitoring
In order to assure that information exists that allows Security Administrators to discover intentional
and unintentional issues with the configuration and/or operation of the system as discussed in
Section 2.3, "Undetected System Activity", compliant TOEs have the capability of generating audit
data targeted at detecting such activity. Auditing of administrative activities provides information
that may hasten corrective action should the system be configured incorrectly. Audit of select
system events can provide an indication of failure of critical portions of the TOE (e.g., a
cryptographic provider process not running) or anomalous activity (e.g., establishment of an
administrative session at a suspicious time, repeated failures to establish sessions or authenticate
to the system) of a suspicious nature.
In some instances there may be a large amount of audit information produced that could
overwhelm the TOE or administrators in charge of reviewing the audit information. The TOE must
be capable of sending audit information to an external trusted entity, which mitigates the possibility
that the generated audit data will cause some kind of denial of service situation on the TOE. This
information must carry reliable timestamps, which will help order the information when sent to the
external device.
Loss of communication with the audit server is problematic. While there are several potential
mitigations to this threat, this PP does not mandate that a specific action takes place; the degree to
which this action preserves the audit information and still allows the TOE to meet its functionality
responsibilities should drive decisions on the suitability of the TOE in a particular environment.
(FAU_GEN.1, FAU_GEN.2, FAU_STG_EXT.1, , FPT_STM.1)
7
3.4
TOE Administration
In order to provide a trusted means for administrators to interact with the TOE, the TOE provides a
password-based logon mechanism. The administrator must have the capability to compose a
strong password, and have mechanisms in place so that the password must be changed regularly.
To avoid attacks where an attacker might observe a password being typed by an administrator,
passwords must be obscured during logon. Session locking or termination must also be
implemented to mitigate the risk of an account being used illegitimately. Passwords must be
stored in an obscured form, and there must be no interface provided for specifically reading the
password or password file such that the passwords are displayed in plain text.
(FIA_UIA_EXT.1, FIA_PMG_EXT.1, FIA_UAU.7, FMT_MTD.1, FMT_SMF.1, FMT_SFR.1, FPT_APW_EXT.1,
FTA_SSL_EXT.1, FTA_SSL.3)
3.5
Residual Information Clearing
In order to counter the threat that user data is inadvertently included in network traffic not
intended by the original sender, the TSF ensures that network packets sent from the TOE do not
include data "left over" from the processing of previous network information.
(FDP_RIP.2)
3.6
TSF Self Test
In order to detect some number of failures of underlying security mechanisms used by the TSF, the
TSF will perform self-tests. The extent of this self testing is left to the product developer, but a
more comprehensive set of self tests should result in a more trustworthy platform on which to
develop enterprise architecture.
(FPT_TST_EXT.1)
8
4
SECURITY REQUIREMENTS
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 3, with
additional extended functional components.
4.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:





Assignment: Indicated with italicized text;
Refinement made by PP author: Indicated with bold text and strikethroughs, if necessary;
Selection: Indicated with underlined text;
Assignment within a Selection: Indicated with italicized and underlined text;
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.
4.2
TOE Security Functional Requirements
This section identifies the Security Functional Requirements for the TOE. The TOE Security
Functional Requirements that appear below in Table 1 are described in more detail in the following
subsections.
Table 1: TOE Security Functional Requirements and Auditable Events
Requirement
FAU_GEN.1
FAU_GEN.2
FAU_STG_EXT.1
FCS_CKM.1
Auditable Events
Additional Audit Record Contents
None.
None.
None.
None.
FCS_CKM_EXT.4
None.
FCS_COP.1(1)
None.
FCS_COP.1(2)
FCS_COP.1(3)
None.
None.
FCS_COP.1(4)
None.
FCS_RBG_EXT.1
None.
FDP_RIP.2
FIA_PMG_EXT.1
FIA_UIA_EXT.1
None.
None.
All use of the identification and
authentication mechanism.
9
Provided user identity, origin of the attempt
(e.g., IP address).
FIA_UAU_EXT.2
FIA_UAU.7
All use of the authentication
mechanism.
None.
FMT_MTD.1
None.
FMT_SMF.1
None.
FMT_SMR.2
FPT_SKP_EXT.1
FPT_APW_EXT.1
FPT_STM.1
None.
None.
None.
Changes to the time.
FPT_TUD_EXT.1
FPT_TST_EXT.1
FTA_SSL_EXT.1
Initiation of update.
None.
Any attempts at unlocking of an
interactive session.
The termination of a remote session
by the session locking mechanism.
The termination of an interactive
session.
None.
Initiation of the trusted channel.
Termination of the trusted channel.
Failure of the trusted channel
functions.
Initiation of the trusted channel.
Termination of the trusted channel.
Failures of the trusted path
functions.
FTA_SSL.3
FTA_SSL.4
FTA_TAB.1
FTP_ITC.1
FTP_TRP.1
Origin of the attempt (e.g., IP address).
10
The old and new values for the time.
Origin of the attempt (e.g., IP address).
No additional information.
No additional information.
No additional information.
No additional information.
Identification of the initiator and target of failed
trusted channels establishment attempt.
Identification of the claimed user identity.
4.2.1 Security Audit (FAU)
FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
a)
b)
c)
d)
Start-up of the audit functions;
All auditable events for the not specified level of audit; and
All administrative actions;
[Specifically defined auditable events listed in Table 1].
Application Note: The ST author can include other auditable events directly in the table; they are not
limited to the list presented.
Many auditable aspects of the SFRs included in this document deal with administrative actions. Item
c above requires all administrative actions to be auditable, so no additional specification of the
auditability of these actions is specified in Table 1.
Assurance Activity:
The evaluator shall check the administrative guide and ensure that it lists all of the auditable events
and provides a format for audit records. Each audit record format type must be covered, along with
a brief description of each field. The evaluator shall check to make sure that every audit event type
mandated by the PP is described and that the description of the fields contains the information
required in FAU_GEN1.2, and the additional information specified in Table 1.
The evaluator shall also make a determination of the administrative actions that are relevant in the
context of this PP. The evaluator shall examine the administrative guide and make a determination
of which administrative commands, including subcommands, scripts, and configuration files, are
related to the configuration (including enabling or disabling) of the mechanisms implemented in the
TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall
document the methodology or approach taken while determining which actions in the
administrative guide are security relevant with respect to this PP. The evaluator may perform this
activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the
requirements.
The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE
generate audit records for the events listed in table 1 and administrative actions. This should
include all instances of an event--for instance, if there are several different I&A mechanisms for a
system, the FIA_UIA_EXT.1 events must be generated for each mechanism. The evaluator shall test
that audit records are generated for the establishment and termination of a channel for each of the
cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the
establishment and termination of a TLS session can be combined with the test for an HTTPS session.
For administrative actions, the evaluator shall test that each action determined by the evaluator
above to be security relevant in the context of this PP is auditable. When verifying the test results,
11
the evaluator shall ensure the audit records generated during testing match the format specified in
the administrative guide, and that the fields in each audit record have the proper entries.
Note that the testing here can be accomplished in conjunction with the testing of the security
mechanisms directly. For example, testing performed to ensure that the administrative guidance
provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the
administrative actions that are needed to verify the audit records are generated as expected.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the PP/ST, [information specified in column three of Table 1].
Application Note: As with the previous component, the ST author should update Table 1 above with
any additional information generated. "Subject identity" in the context of this requirement could
either be the administrator's user id or the affected network interface, for example.
Assurance Activity:
This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1.
FAU_GEN.2 User Identity Association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to
associate each auditable event with the identity of the user that caused the event.
Assurance Activity:
This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1.
FAU_STG_EXT.1 External Audit Trail Storage
FAU_STG_EXT.1.1 The TSF shall be able to [selection: transmit the generated audit data to an
external IT entity, receive and store audit data from an external IT entity] using a trusted channel
implementing the [selection: IPsec, SSH, TLS, TLS/HTTPS] protocol.
Application Note:
For applications of this PP to TOEs that do not act as audit servers, the TOE relies on a non-TOE
audit server for storage and review of audit records. Although the TOE generates audit records, the
storage of these audit records and the ability to allow the administrator to review these audit
records is provided by the operational environment. The ST author chooses the first clause of the
first selection in these cases. This PP can also be used to specify requirements for an audit server; in
this case the second clause of the first selection is used.
12
In the second selection, the ST author chooses the means by which this connection is protected. The
ST author also ensures that the supporting protocol requirement matching the selection is included
in the ST.
Assurance Activity:
For both types of TOEs (those that act as an audit server and those that send data to an external
audit server), there is some amount of local storage. The evaluator shall examine the TSS to ensure
it describes the amount of audit data that are stored locally; what happens when the local audit
data store is full; and how these records are protected against unauthorized access. The evaluator
shall also examine the operational guidance to determine that it describes the relationship between
the local audit data and the audit data that are sent to the audit log server (for TOEs that are not
acting as an audit log server). For example, when an audit event is generated, is it simultaneously
sent to the external server and the local store, or is the local store used as a buffer and “cleared”
periodically by sending the data to the audit server.
TOE acts as audit server
The evaluator shall examine the TSS to ensure it describes the connection supported from non-TOE
entities to send the audit data to the TOE, and how the trusted channel is provided. Testing of the
trusted channel mechanism will be performed as specified in the associated assurance activities for
the particular trusted channel mechanism. The evaluator shall also examine the operational
guidance to ensure it describes how to establish the trusted channel with the TOE, as well as
describe any requirements for other IT entities to connect and send audit data to the TOE (particular
audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE
needed to communicate with other IT entites. The evaluator shall perform the following test for this
requirement:

Test 1: The evaluator shall establish a session between an external IT entity and the TOE
according to the configuration guidance provided. The evaluator shall then examine the
traffic that passes between the IT entity and the TOE during several activities of the
evaluator’s choice designed to generate audit data to be transferred to the TOE. The
evaluator shall observe that these data are not able to be viewed in the clear during this
transfer, and that they are successfully received by the TOE. The evaluator shall perform this
test for each protocol selected in the second selection.
TOE is not an audit server
The evaluator shall examine the TSS to ensure it describes the means by which the audit data are
transferred to the external audit server, and how the trusted channel is provided. Testing of the
trusted channel mechanism will be performed as specified in the associated assurance activities for
the particular trusted channel mechanism. The evaluator shall also examine the operational
guidance to ensure it describes how to establish the trusted channel to the audit server, as well as
describe any requirements on the audit server (particular audit server protocol, version of the
protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit
server. The evaluator shall perform the following test for this requirement:
13

Test 1: The evaluator shall establish a session between the TOE and the audit server
according to the configuration guidance provided. The evaluator shall then examine the
traffic that passes between the audit server and the TOE during several activities of the
evaluator’s choice designed to generate audit data to be transferred to the audit server. The
evaluator shall observe that these data are not able to be viewed in the clear during this
transfer, and that they are successfully received by the audit server. The evaluator shall
record the particular software (name, version) used on the audit server during testing.
4.2.2 Cryptographic Support (FCS)
FCS_CKM.1 Cryptographic Key Generation (for asymmetric keys)
FCS_CKM.1.1
Refinement: The TSF shall generate asymmetric cryptographic keys used for
key establishment in accordance with



[selection:
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 and [selection: P-521, no other curves] (as defined
in FIPS PUB 186-3, “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.
Application Note:
This component requires that the TOE be able to generate the public/private key pairs that are used
for key establishment purposes for the various cryptographic protocols used by the TOE (e.g., IPsec).
If multiple schemes are supported, then the ST author should iterate this requirement to capture this
capability. The scheme used will be chosen by the ST author from the selection.
Since the domain parameters to be used are specified by the requirements of the protocol in this PP,
it is not expected that the TOE will generate domain parameters, and therefore there is no
additional domain parameter validation needed when the TOE complies to the protocols specified in
this PP.
The generated key strength of 2048-bit DSA and rDSA keys need to be 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.
14
Assurance Activity:
The evaluator shall use the key pair generation portions of "The FIPS 186-3 Digital Signature
Algorithm Validation System (DSA2VS)", "The FIPS 186-3 Elliptic Curve Digital Signature Algorithm
Validation System (ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the
requirement above, depending on the selection performed by the ST author. This will require that
the evaluator have a trusted reference implementation of the algorithms that can produce test
vectors that are verifiable during the test.
In order to show that the TSF complies with 800-56A and/or 800-56B, depending on the selections
made, the evaluator shall ensure that the TSS contains the following information:

The TSS shall list all sections of the appropriate 800-56 standard(s) to which the TOE
complies.

For each applicable section listed in the TSS, for all statements that are not "shall" (that
is, "shall not", "should", and "should not"), if the TOE implements such options it shall be
described in the TSS. If the included functionality is indicated as "shall not" or "should
not" in the standard, the TSS shall provide a rationale for why this will not adversely
affect the security policy implemented by the TOE;

For each applicable section of 800-56A and 800-56B (as selected), any omission of
functionality related to "shall" or “should” statements shall be described;
Any TOE-specific extensions, processing that is not included in the documents, or alternative
implementations allowed by the documents that may impact the security requirements the TOE is to
enforce shall be described
FCS_CKM_EXT.4 Cryptographic Key Zeroization
FCS_CKM_EXT.4.1 The TSF shall zeroize all plaintext secret and private cryptographic keys and CSPs
when no longer required.
Application Note: “Cryptographic Critical Security Parameters” are defined in FIPS 140-2 as
“security-related information (e.g., secret and private cryptographic keys, and authentication data
such as passwords and PINs) whose disclosure or modification can compromise the security of a
cryptographic module.”
The zeroization indicated above applies to each intermediate storage area for plaintext
key/cryptographic critical security parameter (i.e., any storage, such as memory buffers, that is
included in the path of such data) upon the transfer of the key/cryptographic critical security
parameter to another location.
Assurance Activity:
The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for
symmetric encryption), private keys, and CSPs used to generate key; when they are zeroized (for
example, immediately after use, on system shutdown, etc.); and the type of zeroization procedure
that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). If
different types of memory are used to store the materials to be protected, the evaluator shall check
15
to ensure that the TSS describes the zeroization procedure in terms of the memory in which the data
are stored (for example, "secret keys stored on flash are zeroized by overwriting once with zeros,
while secret keys stored on the internal hard drive are zeroized by overwriting three times with a
random pattern that is changed before each write").
FCS_COP.1(1) Cryptographic Operation (for data encryption/decryption)
FCS_COP.1.1(1) Refinement: The TSF shall perform [encryption and decryption] in accordance with
a specified cryptographic algorithm [AES operating in [assignment: one or more modes]] and
cryptographic key sizes 128-bits, 256-bits, and [selection: 192 bits, no other key sizes] that meets
the following:

FIPS PUB 197, “Advanced Encryption Standard (AES)”

[Selection: NIST SP 800-38A, NIST SP 800-38B, NIST SP 800-38C, NIST SP 800-38D, NIST
SP 800-38E]
Application Note: For the assignment, the ST author should choose the mode or modes in which AES
operates. For the first selection, the ST author should choose the key sizes that are supported by this
functionality. For the second selection, the ST author should choose the standards that describe the
modes specified in the assignment.
Assurance Activity:
The evaluator shall use tests appropriate to the modes selected in the above requirement from "The
Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES Validation
System (XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block ChainingMessage Authentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode
(GCM) and GMAC Validation System (GCMVS)" (these documents are available from
http://csrc.nist.gov/groups/STM/cavp/index.html) as a guide in testing the requirement above. This
will require that the evaluator have a reference implementation of the algorithms known to be good
that can produce test vectors that are verifiable during the test.
FCS_COP.1(2) Cryptographic Operation (for cryptographic signature)
FCS_COP.1.1(2) Refinement: The TSF shall perform cryptographic signature services in accordance
with a [selection:
(1) Digital Signature Algorithm (DSA) with a key size (modulus) of 2048 bits or greater,
(2) RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of 2048 bits or
greater, or
(3) Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater]
Application Note: As the preferred approach for cryptographic signature, elliptic curves will
be required in future publications of this PP.
that meets the following:
16
Case: Digital Signature Algorithm
 FIPS PUB 186-3, “Digital Signature Standard”
Case: RSA Digital Signature Algorithm
 FIPS PUB 186-2 or FIPS PUB 186-3, “Digital Signature Standard”
Case: Elliptic Curve Digital Signature Algorithm

FIPS PUB 186-3, “Digital Signature Standard”

The TSF shall implement “NIST curves” P-256, P-384 and [selection:
P-521, no other curves] (as defined in FIPS PUB 186-3, “Digital
Signature Standard”).
Application Note: The ST Author should choose the algorithm implemented to perform digital
signatures; if more than one algorithm is available, this requirement (and the corresponding
FCS_CKM.1 requirement) should be iterated to specify the functionality. For the algorithm chosen,
the ST author should make the appropriate assignments/selections to specify the parameters that
are implemented for that algorithm.
For elliptic curve-based schemes, the key size refers to the log2 of the order of the base point. As the
preferred approach for digital signatures, ECDSA will be required in future publications of this PP.
Assurance Activity:
The evaluator shall use the signature generation and signature verification portions of "The Digital
Signature Algorithm Validation System” (DSAVS or DSA2VS), "The Elliptic Curve Digital Signature
Algorithm Validation System” (ECDSAVS or ECDSA2VS), and "The RSA Validation System” (RSAVS) as
a guide in testing the requirement above. The Validation System used shall comply with the
conformance standard identified in the ST (i.e., FIPS PUB 186-2 or FIPS PUB 186-3). This will require
that the evaluator have a reference implementation of the algorithms known to be good that can
produce test vectors that are verifiable during the test.
FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing)
FCS_COP.1.1(3) Refinement: The TSF shall perform [cryptographic hashing services] in accordance
with a specified cryptographic algorithm [selection: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512]
and message digest sizes [selection: 160, 224, 256, 384, 512] bits that meet the following: FIPS Pub
180-3, “Secure Hash Standard.”
Application Note: The selection of the hashing algorithm must correspond to the selection of the
message digest size; for example, if SHA-1 is chosen, then the only valid message digest size
selection would be 160 bits.
In subsequent publications of this PP, it is likely that SHA-1 will no longer be an approved algorithm
for cryptographic hashing.
17
Assurance Activity:
The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing
the requirement above. This will require that the evaluator have a reference implementation of the
algorithms known to be good that can produce test vectors that are verifiable during the test.
FCS_COP.1(4) Cryptographic Operation (for keyed-hash message authentication)
FCS_COP.1.1(4) Refinement: The TSF shall perform [keyed-hash message authentication] in
accordance with a specified cryptographic algorithm HMAC-[selection: SHA-1, SHA-224, SHA-256,
SHA-384, SHA-512], key size [assignment: key size (in bits) used in HMAC], and message digest
sizes [selection: 160, 224, 256, 384, 512] bits that meet the following: FIPS Pub 198-1, "The KeyedHash Message Authentication Code, and FIPS Pub 180-3, “Secure Hash Standard.”
Application Note: In future version of this PP, SHA-1 may be removed as a valid hash algorithm.
Developers are encouraged to transition to the other listed hash algorithms.
Assurance Activity:
The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System
(HMACVS)" as a guide in testing the requirement above. This will require that the evaluator have a
reference implementation of the algorithms known to be good that can produce test vectors that
are verifiable during the test.
Extended: Cryptographic Operation (Random Bit Generation) (FCS_RBG_EXT)
FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation)
FCS_RBG_EXT.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with
[selection, choose one of: NIST Special Publication 800-90 using [selection: Hash_DRBG (any),
HMAC_DRBG (any), CTR_DRBG (AES), Dual_EC_DRBG (any)]; FIPS Pub 140-2 Annex C: X9.31
Appendix 2.4 using AES] seeded by an entropy source that accumulated entropy from [selection,
one or both of: a software-based noise source; a TSF-hardware-based noise source].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum of [selection, choose one
of: 128 bits, 256 bits] of entropy at least equal to the greatest bit length of the keys and
authorization factors that it will generate.
Application Note: NIST Special Pub 800-90, Appendix C describes the minimum entropy
measurement that will probably be required future versions of FIPS-140. If possible this should be
used immediately and will be required in future versions of this PP.
For the first selection in FCS_RBG_EXT.1.1, the ST author should select the standard to which the
RBG services comply (either 800-90 or 140-2 Annex C).
SP 800-90 contains four different methods of generating random numbers; each of these, in turn,
depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select
the function used (if 800-90 is selected), and include the specific underlying cryptographic primitives
used in the requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-224,
18
SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based
implementations for CT_DRBG are allowed. While any of the curves defined in 800-90 are allowed
for Dual_EC_DRBG, the ST author not only must include the curve chosen, but also the hash
algorithm used.
For the second selection in FCS_RBG_EXT.1.1, the ST author indicates whether the sources of entropy
are software-based, hardware-based, or both. If there are multiple sources of entropy, the ST will
elaborate each entropy sources and whether it is hardware- or software-based. Hardware-based
noise sources are preferred.
Note that for FIPS Pub 140-2 Annex C, currently only the method described in NIST-Recommended
Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES
Algorithms, Section 3 is valid. If the key length for the AES implementation used here is different
than that used to encrypt the user data, then FCS_COP.1 may have to be adjusted or iterated to
reflect the different key length. For the selection in FCS_RBG_EXT.1.2, the ST author selects the
minimum number of bits of entropy that is used to seed the RBG.
The ST author also ensures that any underlying functions are included in the baseline requirements
for the TOE.
Assurance Activity:
Documentation shall be produced—and the evaluator shall perform the activities—in accordance
with Annex D, Entropy Documentation and Assessment.
The evaluator shall also perform the following tests, depending on the standard to which the RBG
conforms.
Implementations Conforming to FIPS 140-2, Annex C
The reference for the tests contained in this section is The Random Number Generator Validation
System (RNGVS) [RNGVS]. The evaluator shall conduct the following two tests. Note that the
"expected values" are produced by a reference implementation of the algorithm that is known to
be correct. Proof of correctness is left to each Scheme.
The evaluator shall perform a Variable Seed Test. The evaluator shall provide a set of 128 (Seed,
DT) pairs to the TSF RBG function, each 128 bits. The evaluator shall also provide a key (of the
length appropriate to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value
is incremented by 1 for each set. The seed values shall have no repeats within the set. The
evaluator ensures that the values returned by the TSF match the expected values.
The evaluator shall perform a Monte Carlo Test. For this test, they supply an initial Seed and DT
value to the TSF RBG function; each of these is 128 bits. The evaluator shall also provide a key (of
the length appropriate to the AES algorithm) that is constant throughout the test. The evaluator
then invokes the TSF RBG 10,000 times, with the DT value being incremented by 1 on each iteration,
and the new seed for the subsequent iteration produced as specified in NIST-Recommended
Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES
Algorithms, Section 3. The evaluator ensures that the 10,000th value produced matches the
expected value.
Implementations Conforming to NIST Special Publication 800-90
19
The evaluator shall perform 15 trials for the RBG implementation. If the RBG is configurable, the
evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the
operational guidance contains appropriate instructions for configuring the RBG functionality.
If the RBG has prediction resistance enabled, each trial consists of (1) instantiate drbg, (2) generate
the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The
evaluator verifies that the second block of random bits is the expected value. The evaluator shall
generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy
input, nonce, and personalization string for the instantiate operation. The next two are additional
input and entropy input for the first call to generate. The final two are additional input and entropy
input for the second call to generate. These values are randomly generated. “generate one block of
random bits” means to generate random bits with number of returned bits equal to the Output
Block Length (as defined in NIST SP 800-90).
If the RBG does not have prediction resistance, each trial consists of (1) instantiate drbg, (2)
generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5)
uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The
evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three
are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is
additional input to the first call to generate. The sixth and seventh are additional input and entropy
input to the call to reseed. The final value is additional input to the second generate call.
The following paragraphs contain more information on some of the input values to be
generated/selected by the evaluator.
Entropy input: the length of the entropy input value must equal the seed length.
Nonce: If a nonce is supported (CTR_DRBG with no df does not use a nonce), the nonce bit
length is one-half the seed length.
Personalization string: The length of the personalization string must be <= seed length. If
the implementation only supports one personalization string length, then the same length
can be used for both values. If more than one string length is support, the evaluator shall
use personalization strings of two different lengths. If the implementation does not use a
personalization string, no value needs to be supplied.
Additional input: the additional input bit lengths have the same defaults and restrictions as
the personalization string lengths.
4.2.3 User Data Protection (FDP)
FDP_RIP.2 Full Residual Information Protection
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made
unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] all
objects.
Assurance Activity:
20
“Resources” in the context of this requirement are network packets being sent through (as opposed
to “to”, as is the case when a security administrator connects to the TOE) the TOE. The concern is
that once a network packet is sent, the buffer or memory area used by the packet still contains data
from that packet, and that if that buffer is re-used, those data might remain and make their way
into a new packet. The evaluator shall check to ensure that the TSS describes packet processing to
the extent that they can determine that no data will be reused when processing network packets.
The evaluator shall ensure that this description at a minimum describes how the previous data are
zeroized/overwritten, and at what point in the buffer processing this occurs.
4.2.4 Identification and Authentication (FIA)
FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for
administrative passwords:
1. Passwords shall be able to be composed of any combination of upper and lower case
letters, numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”,
“^”, “&”, “*”, “(“, “)”, *assignment: other characters++;
2. Minimum password length shall settable by the Security Administrator, and support
passwords of 15 characters or greater;
Application Note: The ST author selects the special characters that are supported by TOE; they may
optionally list additional special characters supported using the assignment. "Administrative
passwords" refers to passwords used by administrators at the local console or over protocols that
support passwords, such as SSH and HTTPS.
Assurance Activity:
The evaluator shall examine the operational guidance to determine that it provides guidance to
security administrators on the composition of strong passwords, and that it provides instructions on
setting the minimum password length. The evaluator shall also perform the following tests. Note
that one or more of these tests can be performed with a single test case.

Test 1: The evaluator shall compose passwords that either meet the requirements, or
fail to meet the requirements, in some way. For each password, the evaluator shall
verify that the TOE supports the password. While the evaluator is not required (nor is it
feasible) to test all possible compositions of passwords, the evaluator shall ensure that
all characters, rule characteristics, and a minimum length listed in the requirement are
supported, and justify the subset of those characters chosen for testing.
21
User Identification and Authentication (FIA_UIA)
FIA_UIA_EXT.1
User Identification and Authentication
FIA_UIA_EXT.1.1
The TSF shall allow the following actions prior to requiring the non-TOE
entity to initiate the identification and authentication process:
 Display the warning banner in accordance with FTA_TAB.1;
 [selection: no other actions, [assignment: list of services, actions
performed by the TSF in response to non-TOE requests.]]
FIA_UIA_EXT.1.2
The TSF shall require each administrative user to be successfully identified
and authenticated before allowing any other TSF-mediated actions on
behalf of that administrative user.
Application Note:
This requirement applies to users (administrators and external IT entities) of services available from
the TOE directly, and not services available by connecting through the TOE. While it should be the
case that few or no services are available to external entities prior to identification and
authentication, if there are some available (perhaps ICMP echo) these should be listed in the
assignment statement; otherwise “no other actions” should be selected.
Authentication can be password-based through the local console or through a protocol that
supports passwords (such as SSH), or be certificate based (SSH, TLS).
For communications with external IT entities (e.g., an audit server or NTP server, for instance), such
connections must be performed in accordance with FTP_ITC.1, whose protocols perform
identification and authentication. This means that such communications (e.g., establishing the IPsec
connection to the authentication server) would not have to be specified in the assignment, since
establishing the connection “counts” as initiating the identification and authentication process.
Assurance Activity:
The evaluator shall examine the TSS to determine that it describes the logon process for each logon
method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain
information pertaining to the credentials allowed/used, any protocol transactions that take place,
and what constitutes a “successful logon”. The evaluator shall examine the operational guidance to
determine that any necessary preparatory steps (e.g., establishing credential material such as preshared keys, tunnels, certificates, etc.) to logging in are described. For each supported the login
method, the evaluator shall ensure the operational guidance provides clear instructions for
successfully logging on. If configuration is necessary to ensure the services provided before login are
limited, the evaluator shall determine that the operational guidance provides sufficient instruction
on limiting the allowed services.
The evaluator shall perform the following tests for each method by which administrators access the
TOE (local and remote), as well as for each type of credential supported by the login method:

Test 1: The evaluator shall use the operational guidance to configure the appropriate
credential supported for the login method. For that credential/login method, the
22


evaluator shall show that providing correct I&A information results in the ability to
access the system, while providing incorrect information results in denial of access.
Test 2: The evaluator shall configure the services allowed (if any) according to the
operational guidance, and then determine the services available to an external remote
entity. The evaluator shall determine that the list of services available is limited to those
specified in the requirement.
Test 3: For local access, the evaluator shall determine what services are available to a
local administrator prior to logging in, and make sure this list is consistent with the
requirement.
FIA_UAU_EXT.2 Extended: Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism,
[selection: [assignment: other authentication mechanism(s)], none] to perform administrative user
authentication.
Assurance Activity:
Assurance activities for this requirement are covered under those for FIA_UIA_EXT.1. If other
authentication mechanisms are specified, the evaluator shall include those methods in the activities
for FIA_UIA_EXT.1.
FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the
authentication is in progress at the local console.
Application Note: “Obscured feedback” implies the TSF does not produce a visible display of any
authentication data entered by a user (such as the echoing of a password), although an obscured
indication of progress may be provided (such as an asterisk for each character). It also implies that
the TSF does not return any information during the authentication process to the user that may
provide any indication of the authentication data.
Assurance Activity:
The evaluator shall perform the following test for each method of local login allowed:

Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt,
the evaluator shall verify that at most obscured feedback is provided while entering the
authentication information.
4.2.5 Security Management (FMT)
FMT_MTD.1 Management of TSF Data (for general TSF data)
23
FMT_MTD.1.1 The TSF shall restrict the ability to manage the TSF data to the Security
Administrators.
Application Note: The word “manage” includes but is not limited to create, initialize, view, change
default, modify, delete, clear, and append. This requirement is intended to be the “default”
requirement for management of TSF data; other iterations of FMT_MTD should place different
restrictions or operations available on the specifically-identified TSF data. TSF data includes
cryptographic information as well; managing these data would include the association of a
cryptographic protocol with an interface, for instance.
Assurance Activity:
The evaluator shall review the operational guidance to determine that each of the TSF-datamanipulating functions implemented in response to the requirements of this PP is identified, and
that configuration information is provided to ensure that only administrators have access to the
functions. The evaluator shall examine the TSS to determine that, for each administrative function
identified in the operational guidance; those that are accessible through an interface prior to
administrator log-in are identified. For each of these functions, the evaluator shall also confirm that
the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for
non-administrative users.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:



Ability to administer the TOE locally and remotely;
Ability to update the TOE, and to verify the updates using [selection: digital signature,
published hash, no other mechanism] capability prior to installing those updates;
[selection:
o Ability to configure the list of TOE-provided services available before an entity is
identified and authenticated, as specified in FIA_UIA_EXT.1;
o Ability to configure the cryptographic functionality;
o No other capabilities.]
Application Note: The TOE must provide functionality for both local and remote administration, as
well as the capability for the administrator to verify that updates received came from a trusted
source. They must be capable of performing this action using digital signatures, and optionally a
published hash. The ST author chooses whether the published hash verification option is available
using the first selection, which must match the corresponding selection in FPT_TUD_EXT.1.3. If the
TOE offers the ability for the administrator to configure the services available prior to identification
or authentication, or if any of the cryptographic functionality on the TOE can be configured, then the
ST author makes the appropriate choice or choices in the second selection, otherwise select "no
other capabilities."
Assurance Activity:
24
The security management functions for FMT_SMF.1 are distributed throughout the PP and are
included as part of the requirements in FMT_MTD, FPT_TST_EXT, and any cryptographic
management functions specified in the reference standards. Compliance to these requirements
satisfies compliance with FMT_SMF.1.
FMT_SMR.2
Restrictions on Security Roles
FMT_SMR.2.1
The TSF shall maintain the roles:
 Authorized Administrator.
FMT_SMR.2.2
The TSF shall be able to associate users with roles.
FMT_SMR.2.3
The TSF shall ensure that the conditions
 Authorized Administrator role shall be able to administer the TOE
locally;
 Authorized Administrator role shall be able to administer the TOE
remotely;
are satisfied.
Application Note:
FMT_SMR.2.2 requires that user accounts be associated with only one role. However, note that
multiple users may have the same role, and the TOE is not required to restrict roles to a single
person.
FMT_SMR.2.3 requires that an authorized administrator be able to administer the TOE through the
local console and through a remote mechanism (IPsec, SSH, TLS, TLS/HTTPS). For multiple
component TOEs, only the TOE components providing the management control and configuration of
the other TOE components require a local administration interface.
Assurance Activity:
The evaluator shall review the operational guidance to ensure that it contains instructions for
administering the TOE both locally and remotely, including any configuration that needs to be
performed on the client for remote administration. In the course of performing the testing activities
for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to
repeat each test involving an administrative action with each interface. The evaluator shall ensure,
however, that each supported method of administering the TOE that conforms to the requirements
of this PP be tested; for instance, if the TOE can be administered through a local hardware interface;
SSH; and TLS/HTTPS; then all three methods of administration must be exercised during the
evaluation team’s test activities.
25
4.2.6 Protection of the TSF (FPT)
FPT_SKP_EXT.1
Extended: Protection of TSF Data (for reading of all symmetric keys)
FPT_SKP_EXT.1.1
The TSF shall prevent reading of all pre-shared keys, symmetric keys,
and private keys.
Application Note:
The intent of the requirement is that an administrator is unable to read or view the identified keys
(stored or ephemeral) through “normal” interfaces. While it is understood that the administrator
could directly read memory to view these keys, do so is not a trivial task and may require substantial
work on the part of an administrator. Since the administrator is considered a trusted agent, it is
assumed they would not endeavour in such an activity.
Assurance Activity:
The evaluator shall examine the TSS to determine that it details how any pre-shared keys, symmetric
keys, and private keys are stored and that they are unable to be viewed through an interface
designed specifically for that purpose, as outlined in the application note. If these values are not
stored in plaintext, the TSS shall describe how they are protected/obscured.
FPT_APW_EXT.1
Extended: Protection of Administrator Passwords
FPT_APW_EXT.1.1
The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.2
The TSF shall prevent the reading of plaintext passwords.
Application Note:
The intent of the requirement is that raw password authentication data are not stored in the clear,
and that no user or administrator is able to read the plaintext password through “normal”
interfaces. An all-powerful administrator of course could directly read memory to capture a
password but is trusted not to do so.
In this version of the PP there are no requirements on the method used to store the passwords in
non-plaintext form, but cryptographic methods based on the requirements in FCS_COP are
preferred. In future versions of this PP, FCS_COP-based cryptographic methods that conform to the
Level 2 Credential Storage requirements from NIST SP 800-63 will be required.
Assurance Activity:
The evaluator shall examine the TSS to determine that it details all authentication data that are
subject to this requirement, and the method used to obscure the plaintext password data when
stored. The TSS shall also detail passwords are stored in such a way that they are unable to be
viewed through an interface designed specifically for that purpose, as outlined in the application
note.
26
FPT_STM.1 Reliable Time Stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use.
Assurance Activity:
The evaluator shall examine the TSS to ensure that it lists each security function that makes use of
time. The TSS provides a description of how the time is maintained and considered reliable in the
context of each of the time related functions.
The evaluator examines the operational guidance to ensure it instructs the administrator how to set
the time. If the TOE supports the use of an NTP server, the operational guidance instructs how a
communication path is established between the TOE and the NTP server, and any configuration of
the NTP client on the TOE to support this communication.

Test 1: The evaluator uses the operational guide to set the time. The evaluator shall
then use an available interface to observe that the time was set correctly.

Test2: [conditional] If the TOE supports the use of an NTP server; the evaluator shall
use the operational guidance to configure the NTP client on the TOE, and set up a
communication path with the NTP server. The evaluator will observe that the NTP
server has set the time to what is expected. If the TOE supports multiple
cryptographic protocols for establishing a connection with the NTP server, the
evaluator shall perform this test using each supported protocol.
Extended: Trusted Update (FPT_TUD_EXT.1)
FPT_TUD_EXT.1 Extended: Trusted Update
FPT_TUD_EXT.1.1 The TSF shall provide security administrators the ability to query the current
version of the TOE firmware/software.
FPT_TUD_EXT.1.2 The TSF shall provide security administrators the ability to initiate updates to TOE
firmware/software.
FPT_TUD_EXT.1.3 The TSF shall provide a means to verify firmware/software updates to the TOE
using a [selection: digital signature mechanism, published hash] prior to installing those updates.
Application Note: The digital signature mechanism referenced in the third element is the one
specified in FCS_COP.1(2). The published hash referenced is generated by one of the functions
specified in FCS_COP.1(3). The ST author should choose the mechanism implemented by the TOE; it
is acceptable to implement both mechanisms.
27
Assurance Activity:
Updates to the TOE either have a hash associated with them, or are signed by an authorized source.
If digital signatures are used, the definition of an authorized source is contained in the TSS, along
with a description of how the certificates used by the update verification mechanism are contained
on the device. The evaluator ensures this information is contained in the TSS. The evaluator also
ensures that the TSS (or the operational guidance) describes how the candidate updates are
obtained; the processing associated with verifying the digital signature or calculating the hash of the
updates; and the actions that take place for successful (hash or signature was verified) and
unsuccessful (hash or signature could not be verified) cases. The evaluator shall perform the
following tests:

Test 1: The evaluator performs the version verification activity to determine the current
version of the product. The evaluator obtains a legitimate update using procedures
described in the operational guidance and verifies that it is successfully installed on the
TOE. Then, the evaluator performs a subset of other assurance activity tests to
demonstrate that the update functions as expected. After the update, the evaluator
performs the version verification activity again to verify the version correctly
corresponds to that of the update.

Test 2: The evaluator performs the version verification activity to determine the current
version of the product. The evaluator obtains or produces an illegitimate update, and
attempts to install it on the TOE. The evaluator verifies that the TOE rejects the update.
FPT_TST_EXT.1: TSF Testing
FPT_TST_EXT.1.1 The TSF shall run a suite of self tests during initial start-up (on power on) to
demonstrate the correct operation of the TSF.
Assurance Activity:
The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF on
start-up; this description should include an outline of what the tests are actually doing (e.g., rather
than saying "memory is tested", a description similar to "memory is tested by writing a value to each
memory location and reading it back to ensure it is identical to what was written" shall be used).
The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to
demonstrate that the TSF is operating correctly.
The evaluator shall also ensure that the operational guidance describes the possible errors that may
result from such tests, and actions the administrator should take in response; these possible errors
shall correspond to those described in the TSS.
4.2.7 TOE Access (FTA)
FTA_SSL_EXT.1 TSF-initiated Session Locking
28
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [selection:


lock the session - disable any activity of the user’s data access/display devices other
than unlocking the session, and requiring that the administrator re-authenticate to the
TSF prior to unlocking the session;
terminate the session]
after a Security Administrator-specified time period of inactivity.
Assurance Activity:
The evaluator shall perform the following test:

Test 1: The evaluator follows the operational guidance to configure several different
values for the inactivity time period referenced in the component. For each period
configured, the evaluator establishes a local interactive session with the TOE. The
evaluator then observes that the session is either locked or terminated after the
configured time period. If locking was selected from the component, the evaluator then
ensures that re-authentication is needed when trying to unlock the session.
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after a [Security
Administrator-configurable time interval of session inactivity].
Assurance Activity:
The evaluator shall perform the following test:

Test 1: The evaluator follows the operational guidance to configure several different
values for the inactivity time period referenced in the component. For each period
configured, the evaluator establishes a remote interactive session with the TOE. The
evaluator then observes that the session is terminated after the configured time period.
FTA_SSL.4
User-initiated Termination
FTA_SSL.4.1
The TSF shall allow Administrator-initiated termination of the
Administrator’s own interactive session.
Assurance Activity:
The evaluator shall perform the following test:

Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator
then follows the operational guidance to exit or log off the session and observes that
the session has been terminated.
29

Test 2: The evaluator initiates an interactive remote session with the TOE. The
evaluator then follows the operational guidance to exit or log off the session and
observes that the session has been terminated.
FTA_TAB.1 Default TOE Access Banners
FTA_TAB.1.1 Refinement: Before establishing an administrative user session the TSF shall display a
Security Administrator-specified advisory notice and consent warning message regarding use of
the TOE.
Application Note: This requirement is intended to apply to interactive sessions between a human
user and a TOE. IT entities establishing connections or programmatic connections (e.g., remote
procedure calls over a network) are not required to be covered by this requirement.
Assurance Activity:
The evaluator shall check the TSS to ensure that it details each method of access (local and remote)
available to the administrator (e.g., serial port, SSH, HTTPS). The evaluator shall also perform the
following test:

Test 1: The evaluator follows the operational guidance to configure a notice and consent
warning message. The evaluator shall then, for each method of access specified in the
TSS, establish a session with the TOE. The evaluator shall verify that the notice and
consent warning message is displayed in each instance.
4.2.8 Trusted Path/Channels (FTP)
Trusted Channel (FTP_ITC)
FTP_ITC.1
Inter-TSF trusted channel
FTP_ITC.1.1
Refinement: The TSF shall use [selection: IPsec, SSH, TLS, TLS/HTTPS]
to provide a trusted communication channel between itself and
authorized IT entities supporting the following capabilities: audit
server, [selection: authentication server, assignment: [other
capabilities]] 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 TSF shall permit the TSF, or the authorized IT entities to initiate
communication via the trusted channel.
FTP_ ITC.1.3
The TSF shall initiate communication via the trusted channel for
[assignment: list of services for which the TSF is able to initiate
communications].
30
Application Note:
The intent of the above requirement is to use a cryptographic protocol to protect external
communications with authorized IT entities that the TOE interacts with to perform its functions. This
is not, however, to be used to specify VPN Gateway functionality; a separate VPN Protection Profile
should be used in these instances. Protection (by one of the listed protocols) is required at least for
communications with the server that collects the audit information. If it communicates with an
authentication server (e.g., RADIUS), then the ST author chooses “authentication server” in
FTP_ITC.1.1 and this connection must be protected by one of the listed protocols. If other authorized
IT entities (e.g., NTP server) are protected, the ST author makes the appropriate assignments (for
those entities) and selections (for the protocols that are used to protect those connections). After the
ST author has made the selections, they are to select the detailed requirements in Annex C
corresponding to their protocol selection to put in the ST. To summarize, the connection to an
external audit collection server is required to be protected by one of the listed protocols. If an
external authentication server is supported, then it is required to protect that connection with one of
the listed protocols. For any other external server, external communications are not required to be
protected, but if protection is claimed, then it must be protected with one of the identified protocols.
While there are no requirements on the party initiating the communication, the ST author lists in the
assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the
authorized IT entity.
The requirement implies that not only are communications protected when they are initially
established, but also on resumption after an outage. It may be the case that some part of the TOE
setup involves manually setting up tunnels to protect other communication, and if after an outage
the TOE attempts to re-establish the communication automatically with (the necessary) manual
intervention, there may be a window created where an attacker might be able to gain critical
information or compromise a connection.
Assurance Activity:
The evaluator shall examine the TSS to determine that, for all communications with authorized IT
entities identified in the requirement, each communications mechanism is identified in terms of the
allowed protocols for that IT entity. The evaluator shall also confirm that all protocols listed in the
TSS are specified and included in the requirements in the ST. The evaluator shall confirm that the
operational guidance contains instructions for establishing the allowed protocols with each
authorized IT entity, and that it contains recovery instructions should a connection be
unintentionally broken. The evaluator shall also perform the following tests:
a. Test 1: The evaluators shall ensure that communications using each protocol with each
authorized IT entity is tested during the course of the evaluation, setting up the
connections as described in the operational guidance and ensuring that communication
is successful.
b. Test 2: For each protocol that the TOE can initiate as defined in the requirement, the
evaluator shall follow the operational guidance to ensure that in fact the communication
channel can be initiated from the TOE.
31
c. Test 3: The evaluator shall ensure, for each communication channel with an authorized
IT entity, the channel data is not sent in plaintext.
d. Test 4: The evaluator shall ensure, for each communication channel with an authorized
IT entity, modification of the channel data is detected by the TOE.
e. Test 5: The evaluators shall, for each protocol associated with each authorized IT entity
tested during test 1, the connection is physically interrupted. The evaluator shall ensure
that when physical connectivity is restored, communications are appropriately
protected.
Further assurance activities are associated with the specific protocols.
Trusted Path (FTP_TRP)
FTP_TRP.1
Trusted Path
FTP_TRP.1.1
Refinement: The TSF shall use [selection, choose at least one of: IPsec,
SSH, TLS, TLS/HTTPS] provide a trusted communication path between
itself and remote administrators that is logically distinct from other
communication paths and provides assured identification of its end
points and protection of the communicated data from disclosure and
detection of modification of the communicated data.
FTP_TRP.1.2
Refinement: The TSF shall permit remote administrators to initiate
communication via the trusted path.
FTP_TRP.1.3
The TSF shall require the use of the trusted path for initial administrator
authentication and all remote administration actions.
Application Note:
This requirement ensures that authorized remote administrators initiate all communication with the TOE
via a trusted path, and that all communications with the TOE by remote administrators is performed over
this path. The data passed in this trusted communication channel are encrypted as defined the protocol
chosen in the first selection. The ST author chooses the mechanism or mechanisms supported by the
TOE, and then ensures the detailed requirements in Annex C corresponding to their selection are copied
to the ST if not already present.
Assurance Activity:
The evaluator shall examine the TSS to determine that the methods of remote TOE administration
are indicated, along with how those communications are protected. The evaluator shall also
confirm that all protocols listed in the TSS in support of TOE administration are consistent with those
specified in the requirement, and are included in the requirements in the ST. The evaluator shall
confirm that the operational guidance contains instructions for establishing the remote
administrative sessions for each supported method. The evaluator shall also perform the following
tests:
32
a.
Test 1: The evaluators shall ensure that communications using each specified (in the
operational guidance) remote administration method is tested during the course of the
evaluation, setting up the connections as described in the operational guidance and
ensuring that communication is successful.
b.
Test 2: For each method of remote administration supported, the evaluator shall
follow the operational guidance to ensure that there is no available interface that can be
used by a remote user to establish a remote administrative sessions without invoking the
trusted path.
c.
Test 3: The evaluator shall ensure, for each method of remote administration, the
channel data is not sent in plaintext.
d.
Test 4: The evaluator shall ensure, for each method of remote administration,
modification of the channel data is detected by the TOE.
Further assurance activities are associated with the specific protocols.
4.3
Security Assurance Requirements
The Security Objectives for the TOE in Section 3 were constructed to address threats identified in
Section 2. The Security Functional Requirements (SFRs) in Section 4.2 are a formal instantiation of
the Security Objectives. The PP draws from the CC Security Assurance Requirements (SARs) to
frame the extent to which the evaluator assesses the documentation applicable for the evaluation
and performs independent testing.
While this section contains the complete set of SARs from the CC, the Assurance Activities to be
performed by an evaluator are detailed both in Section 4.2 as well as in this section.
The general model for evaluating TOEs against STs written to conform to this PP is as follows:
After the ST has been approved for evaluation, the Common Criteria Testing Laboratory (CCTL) will
obtain the TOE, supporting IT environment, and the administrative guides for the TOE. The
Assurance Activities listed in the ST (which will be refined by the CCTL to be TOE-specific, either
within the ST or in a separate document) will then be performed by the CCTL. The results of these
activities will be documented and presented (along with the administrative guidance used) for
validation.
For each assurance family, “Developer Notes” are provided on the developer action elements to
clarify what, if any, additional documentation/activity needs to be provided by the developer. For
the content/presentation and evaluator activity elements, additional assurance activities are
described as a whole for the family, rather than for each element. Additionally, the assurance
activities described in this section are complementary to those specified in Section 4.2.
The TOE security assurance requirements, summarized in Table 2, identify the management and
evaluative activities required to address the threats identified in Section 2 of this PP.
Table 2: TOE Security Assurance Requirements
Assurance Class
Assurance
Components
Assurance Components Description
33
Development
Guidance Documents
Tests
Vulnerability Assessment
Life Cycle Support
ADV_FSP.1
Basic Functional Specification
AGD_OPE.1
Operational user guidance
AGD_PRE.1
Preparative User guidance
ATE_IND.1
Independent testing - conformance
AVA_VAN.1
Vulnerability analysis
ALC_CMC.1
Labeling of the TOE
ALC_CMS.1
TOE CM coverage
4.3.1 Class ADV: Development
The information about the TOE is contained in the guidance documentation available to the end
user as well as the TOE Summary Specification (TSS) portion of the ST. While it is not required that
the TOE developer write the TSS, the TOE developer must concur with the description of the
product that is contained in the TSS as it relates to the functional requirements. The Assurance
Activities contained in Section 4.2, should provide the ST authors with sufficient information to
determine the appropriate content for the TSS section.
4.3.1.1 ADV_FSP.1 Basic Functional Specification
The functional specification describes the Target Security Functions Interfaces (TSFIs). It is not
necessary to have a formal or complete specification of these interfaces. Additionally, because
TOEs conforming to this PP will necessarily have interfaces to the Operational Environment that are
not directly invokable by TOE users, there is little point specifying that such interfaces be described
in and of themselves since only indirect testing of such interfaces may be possible. For this PP, the
activities for this family should focus on understanding the interfaces presented in the TSS in
response to the functional requirements and the interfaces presented in the AGD documentation.
No additional “functional specification” documentation is necessary to satisfy the assurance
activities specified.
The interfaces that need to be evaluated are characterized through the information needed to
perform the assurance activities listed, rather than as an independent, abstract list.
Developer action elements:
ADV_FSP.1.1D
ADV_FSP.1.2D
Developer Note:
The developer shall provide a functional specification.
The developer shall provide a tracing from the functional
specification to the SFRs.
As indicated in the introduction to this section, the functional
specification is comprised of the information contained in the
34
AGD_OPE and AGD_PRE documentation, coupled with the
information provided in the TSS of the ST. The assurance activities in
the functional requirements point to evidence that should exist in
the documentation and TSS section; since these are directly
associated with the SFRs, the tracing in element ADV_FSP.1.2D is
implicitly already done and no additional documentation is
necessary.
Content and presentation elements:
ADV_FSP.1.1C
ADV_FSP.1.2C
ADV_FSP.1.3C
ADV_FSP.1.4C
ADV_ FSP.1.1E
ADV_ FSP.1.2E
The functional specification shall describe the purpose and method
of use for each SFR-enforcing and SFR-supporting TSFI.
The functional specification shall identify all parameters associated
with each SFR-enforcing and SFR-supporting TSFI.
The functional specification shall provide rationale for the implicit
categorization of interfaces as SFR-non-interfering.
The tracing shall demonstrate that the SFRs trace to TSFIs in the
functional specification.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
The evaluator shall determine that the functional specification is an
accurate and complete instantiation of the SFRs.
Assurance Activity:
There are no specific assurance activities associated with these SARs. The functional specification
documentation is provided to support the evaluation activities described in Section 4.2, and other
activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional
specification information is implicitly assessed by virtue of the other assurance activities being
performed; if the evaluator is unable to perform an activity because the there is insufficient interface
information, then an adequate functional specification has not been provided.
4.3.2 Class AGD: Guidance Documents
The guidance documents will be provided with the developer’s security target. Guidance must
include a description of how the authorized user verifies that the Operational Environment can
fulfill its role for the security functionality. The documentation should be in an informal style and
readable by an authorized user.
Guidance must be provided for every operational environment that the product supports as
claimed in the ST. This guidance includes


instructions to successfully install the TOE in that environment; and
instructions to manage the security of the TOE as a product and as a component of the
larger operational environment.
Guidance pertaining to particular security functionality is also provided; specific requirements on
such guidance are contained in the assurance activities specified in Section 4.2.
35
4.3.2.1 AGD_OPE.1 Operational User Guidance
Developer action elements:
AGD_OPE.1.1D
Developer Note:
The developer shall provide operational user guidance.
Rather than repeat information here, the developer should review the
assurance activities for this component to ascertain the specifics of the
guidance that the evaluator will be checking for. This will provide the
necessary information for the preparation of acceptable guidance.
Content and presentation elements:
AGD_OPE.1.1C
AGD_OPE.1.2C
AGD_OPE.1.3C
AGD_OPE.1.4C
AGD_OPE.1.5C
AGD_OPE.1.6C
AGD_OPE.1.7C
AGD_OPE.1.1E
The operational user guidance shall describe, for each user role, the useraccessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.
The operational user guidance shall describe, for each user role, how to use the
available interfaces provided by the TOE in a secure manner.
The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control
of the user, indicating secure values as appropriate.
The operational user guidance shall, for each user role, clearly present each
type of security-relevant event relative to the user-accessible functions that
need to be performed, including changing the security characteristics of entities
under the control of the TSF.
The operational user guidance shall identify all possible modes of operation of
the TOE (including operation following failure or operational error), their
consequences, and implications for maintaining secure operation.
The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfill the security objectives for the
operational environment as described in the ST.
The operational user guidance shall be clear and reasonable.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Assurance Activity:
Some of the contents of the operational guidance will be verified by the assurance activities in
Section 4.2 and evaluation of the TOE according to the CEM. The following additional information is
also required.
The operational guidance shall at a minimum list the processes running (or that could run) on the
TOE in its evaluated configuration during its operation that are capable of processing data received
on the network interfaces (there are likely more than one of these, and this is not limited to the
process that "listens" on the network interface). It is acceptable to list all processes running (or that
could run) on the TOE in its evaluated configuration instead of attempting to determine just those
that process the network data. For each process listed, the administrative guidance will contain a
36
short (e.g., one- or two-line) description of the process' function, and the privilege with which the
service runs. "Privilege" includes the hardware privilege level (e.g., ring 0, ring 1), any software
privileges specifically associated with the process, and the privileges associated with the user role
the process runs as or under.
The operational guidance shall contain instructions for configuring the cryptographic engine
associated with the evaluated configuration of the TOE. It shall provide a warning to the
administrator that use of other cryptographic engines was not evaluated nor tested during the CC
evaluation of the TOE.
The documentation must describe the process for verifying updates to the TOE, either by checking
the hash or by verifying a digital signature. The evaluator shall verify that this process includes the
following steps:
1. For hashes, a description of where the hash for a given update can be obtained. For
digital signatures, instructions for obtaining the certificate that will be used by the
FCS_COP.1(2) mechanism to ensure that a signed update has been received from the
certificate owner. This may be supplied with the product initially, or may be obtained by
some other means.
2. Instructions for obtaining the update itself. This should include instructions for making
the update accessible to the TOE (e.g., placement in a specific directory).
3. Instructions for initiating the update process, as well as discerning whether the process
was successful or unsuccessful. This includes generation of the hash/digital signature.
The TOE will likely contain security functionality that does not fall in the scope of evaluation under
this PP. The operational guidance shall make it clear to an administrator which security
functionality is covered by the evaluation activities.
4.3.2.2 AGD_PRE.1 Preparative Procedures
Developer action elements:
AGD_PRE.1.1D
Developer Note:
The developer shall provide the TOE, including its preparative procedures.
As with the operational guidance, the developer should look to the
assurance activities to determine the required content with respect to
preparative procedures.
Content and presentation elements:
AGD_ PRE.1.1C
AGD_ PRE.1.2C
The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer's delivery
procedures.
The preparative procedures shall describe all the steps necessary for secure
37
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.
Evaluator action elements:
AGD_ PRE.1.1E
AGD_ PRE.1.2E
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
The evaluator shall apply the preparative procedures to confirm that the TOE
can be prepared securely for operation.
Assurance Activity:
As indicated in the introduction above, there are significant expectations with respect to the
documentation—especially when configuring the operational environment to support TOE
functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE
adequately addresses all platforms claimed for the TOE in the ST.
4.3.3 Class ATE: Tests
Testing is specified for functional aspects of the system as well as aspects that take advantage of
design or implementation weaknesses. The former is done through the ATE_IND family, while the
latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on
advertised functionality and interfaces with dependency on the availability of design information.
One of the primary outputs of the evaluation process is the test report as specified in the following
requirements.
4.3.3.1 ATE_IND.1 Independent Testing - Conformance
Testing is performed to confirm the functionality described in the TSS as well as the administrative
(including configuration and operational) documentation provided. The focus of the testing is to
confirm that the requirements specified in Section 4.2 are being met, although some additional
testing is specified for SARs in Section 4.3. The Assurance Activities identify the additional testing
activities associated with these components. The evaluator produces a test report documenting
the plan for and results of testing, as well as coverage arguments focused on the platform/TOE
combinations that are claiming conformance to this PP.
Developer action elements:
ATE_IND.1.1D
The developer shall provide the TOE for testing.
Content and presentation elements:
ATE_IND.1.1C
The TOE shall be suitable for testing.
Evaluator action elements:
ATE_IND.1.1E
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
The evaluator shall test a subset of the TSF to confirm that the TSF operates as
ATE_IND.1.2E
38
specified.
Assurance Activity:
The evaluator shall prepare a test plan and report documenting the testing aspects of the system.
The test plan covers all of the testing actions contained in the CEM and the body of this PP’s
Assurance Activities. While it is not necessary to have one test case per test listed in an Assurance
Activity, the evaluator must document in the test plan that each applicable testing requirement in
the ST is covered.
The test plan identifies the platforms to be tested, and for those platforms not included in the test
plan but included in the ST, the test plan provides a justification for not testing the platforms. This
justification must address the differences between the tested platforms and the untested platforms,
and make an argument that the differences do not affect the testing to be performed. It is not
sufficient to merely assert that the differences have no affect; rationale must be provided. If all
platforms claimed in the ST are tested, then no rationale is necessary.
The test plan describes the composition of each platform to be tested, and any setup that is
necessary beyond what is contained in the AGD documentation. It should be noted that the
evaluator is expected to follow the AGD documentation for installation and setup of each platform
either as part of a test or as a standard pre-test condition. This may include special test drivers or
tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver
or tool will not adversely affect the performance of the functionality by the TOE and its platform.
This also includes the configuration of the cryptographic engine to be used. The cryptographic
algorithms implemented by this engine are those specified by this PP and used by the cryptographic
protocols being evaluated (IPsec, TLS/HTTPS, SSH).
The test plan identifies high-level test objectives as well as the test procedures to be followed to
achieve those objectives. These procedures include expected results. The test report (which could
just be an annotated version of the test plan) details the activities that took place when the test
procedures were executed, and includes the actual results of the tests. This shall be a cumulative
account, so if there was a test run that resulted in a failure; a fix installed; and then a successful rerun of the test, the report would show a “fail” and “pass” result (and the supporting details), and not
just the “pass” result.
4.3.4 Class AVA: Vulnerability Assessment
For the first generation of this protection profile, the evaluation lab is expected to survey open
sources to discover what vulnerabilities have been discovered in these types of products. In most
cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until
penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will
not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment
on the likelihood of these vulnerabilities given the documentation provided by the vendor. This
information will be used in the development of penetration testing tools and for the development
of future protection profiles.
39
4.3.4.1 AVA_VAN.1 Vulnerability Survey
Developer action elements:
AVA_VAN.1.1D
The developer shall provide the TOE for testing.
Content and presentation elements:
AVA_VAN.1.1C
The TOE shall be suitable for testing.
Evaluator action elements:
AVA_VAN.1.1E
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
The evaluator shall perform a search of public domain sources to
identify potential vulnerabilities in the TOE.
The evaluator shall conduct penetration testing, based on the
identified potential vulnerabilities, to determine that the TOE is
resistant to attacks performed by an attacker possessing Basic attack
potential.
AVA_VAN.1.2E
AVA_VAN.1.3E
Assurance Activity:
As with ATE_IND, the evaluator shall generate a report to document their findings with respect to
this requirement. This report could physically be part of the overall test report mentioned in
ATE_IND, or a separate document. The evaluator performs a search of public information to
determine the vulnerabilities that have been found in network infrastructure devices and the
implemented communication protocols in general, as well as those that pertain to the particular
TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For
each vulnerability found, the evaluator either provides a rationale with respect to its nonapplicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to
confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed
to take advantage of the vulnerability. For example, if the vulnerability can be detected by pressing
a key combination on boot-up, a test would be suitable at the assurance level of this PP. If
exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a
test would not be suitable and an appropriate justification would be formulated.
4.3.5 Class ALC: Life-cycle Support
At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to enduser-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development
and configuration management process. This is not meant to diminish the critical role that a
developer’s practices play in contributing to the overall trustworthiness of a product; rather, it’s a
reflection on the information to be made available for evaluation at this assurance level.
40
4.3.5.1 ALC_CMC.1 Labeling of the TOE
This component is targeted at identifying the TOE such that it can be distinguished from other
products or versions from the same vendor and can be easily specified when being procured by an
end user.
Developer action elements:
ALC_CMC.1.1D
The developer shall provide the TOE and a reference for the TOE.
Content and presentation elements:
ALC_CMC.1.1C
The TOE shall be labeled with its unique reference.
Evaluator action elements:
ALC_CMC.2.1E
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Assurance Activity:
The evaluator shall check the ST to ensure that it contains an identifier (such as a product
name/version number) that specifically identifies the version that meets the requirements of the ST.
Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure
that the version number is consistent with that in the ST. If the vendor maintains a web site
advertising the TOE, the evaluator shall examine the information on the web site to ensure that the
information in the ST is sufficient to distinguish the product.
4.3.5.2 ALC_CMS.1 TOE CM Coverage
Given the scope of the TOE and its associated evaluation evidence requirements, this component’s
assurance activities are covered by the assurance activities listed for ALC_CMC.1.
Developer action elements:
ALC_CMS.2.1D
The developer shall provide a configuration list for the TOE.
Content and presentation elements:
ALC_CMS.2.1C
The configuration list shall include the following: the TOE itself; and the
evaluation evidence required by the SARs.
ALC_CMS.2.2C
The configuration list shall uniquely identify the configuration items.
Evaluator action elements:
ALC_CMS.2.1E
The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
41
Assurance Activity:
The “evaluation evidence required by the SARs” in this PP is limited to the information in the ST
coupled with the guidance provided to administrators and users under the AGD requirements. By
ensuring that the TOE is specifically identified and that this identification is consistent in the ST and
in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly
confirms the information required by this component.
42
RATIONALE
The rationale tracing the threats to the objectives and the objectives to the requirements is
contained in the prose in Sections 2.0 and 3.0. The only outstanding mappings are those for the
Assumptions and Organizational Security Policies; those are contained in Annex A below.
ANNEX A: SUPPORTING TABLES
In this Protection Profile, the focus in the initial sections of the document is to use a narrative
presentation in an attempt to increase the overall understandability of the threats to network
devices; the methods used to mitigate those threats; and the extent of the mitigation achieved by
compliant TOEs. This presentation style does not readily lend itself to a formalized evaluation
activity, so this Annex contains the tabular artifacts that can be used for the evaluation activities
associated with this document.
Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
Operational 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.
PP authors should ensure that the assumptions still hold for their particular technology; the table
should be modified as appropriate.
Table 3: TOE Assumptions
Assumption Name
Assumption Definition
A.NO_GENERAL_PURPOSE
It is assumed that there are no general-purpose computing capabilities
(e.g., compilers or user applications) available on the TOE, other than those
services necessary for the operation, administration and support of the
TOE.
Physical security, commensurate with the value of the TOE and the data it
contains, is assumed to be provided by the environment.
TOE Administrators are trusted to follow and apply all administrator
guidance in a trusted manner.
A.PHYSICAL
A.TRUSTED_ADMIN
Threats
The following threats should be integrated into the threats that are specific to the technology by
the PP authors when including the requirements described in this document. Modifications,
omissions, and additions to the requirements may impact this list, so the PP author should modify
or delete these threats as appropriate.
Table 4: Threats
43
Threat Name
Threat Definition
T.ADMIN_ERROR
An administrator may unintentionally install or configure the TOE
incorrectly, resulting in ineffective security mechanisms.
Security mechanisms of the TOE may fail, leading to a compromise of
the TSF.
Malicious remote users or external IT entities may take actions that
adversely affect the security of the TOE. These actions may remain
undetected and thus their effects cannot be effectively mitigated.
A user may gain unauthorized access to the TOE data and TOE
executable code. 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.
A malicious party attempts to supply the end user with an update to
the product that may compromise the security features of the TOE.
User data may be inadvertently sent to a destination not intended by
the original sender.
T.TSF_FAILURE
T.UNDETECTED_ACTIONS
T.UNAUTHORIZED_ACCESS
T.UNAUTHORIZED_UPDATE
T.USER_DATA_REUSE
Organizational Security Policies
An organizational security policy is a set of rules, practices, and procedures imposed by an
organization to address its security needs. PP Authors should ensure that any policies that apply to
their particular technology are captured in the following table, and that the policies listed below are
applicable.
Table 5: Organizational Security Policies
Policy Name
Policy Definition
P.ACCESS_BANNER
The TOE shall display an initial
banner describing restrictions of use,
legal agreements, or any other
appropriate information to which
users consent by accessing the TOE.
Security Objectives for the TOE
Table 6: Security Objectives for the TOE
TOE Security Obj.
TOE Security Objective Definition
O.PROTECTED_COMMUNICATIONS
The TOE will provide protected communication channels for
administrators, other parts of a distributed TOE, and
authorized IT entities.
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.
O.VERIFIABLE_UPDATES
44
TOE Security Obj.
TOE Security Objective Definition
O.SYSTEM_MONITORING
The TOE will provide the capability to generate audit data and
send those data to an external IT entity.
The TOE will display an advisory warning regarding use of the
TOE.
The TOE will provide mechanisms to ensure that only
administrators are able to log in and configure the TOE, and
provide protections for logged-in administrators.
The TOE will ensure that any data contained in a protected
resource is not available when the resource is reallocated.
The TOE shall provide mechanisms that mitigate the risk of
unattended sessions being hijacked.
The TOE will provide the capability to test some subset of its
security functionality to ensure it is operating properly.
O.DISPLAY_BANNER
O.TOE_ADMINISTRATION
O.RESIDUAL_INFORMATION_CLEARING
O.SESSION_LOCK
O.TSF_SELF_TEST
The following table contains objectives for the Operational Environment. As assumptions are added
to the PP, these objectives should be augmented to reflect such additions.
Table 7: Security Objectives for the Operational Environment
TOE Security Obj.
TOE Security Objective Definition
OE.NO_GENERAL_PURPOSE
There are no general-purpose computing capabilities (e.g.,
compilers or user applications) available on the TOE, other than
those services necessary for the operation, administration and
support of the TOE.
Physical security, commensurate with the value of the TOE and
the data it contains, is provided by the environment.
TOE Administrators are trusted to follow and apply all
administrator guidance in a trusted manner.
OE.PHYSICAL
OE.TRUSTED_ADMIN
45
ANNEX B: NIST SP 800-53/CNSS 1253 MAPPING
Several of the NIST SP 800-53/CNSS 1253 controls are either fully or partially addressed by
compliant TOEs. This section outlines the requirements that are addressed, and can be used by
certification personnel to determine what, if any, additional testing is required when the TOE is
incorporated into its operational configuration.
Application Note: In this version, only a simple mapping is provided. In future versions, additional
narrative will be included that will provide further information for the certification team. This
additional information will include details regarding the SFR to control mapping discussing what
degree of compliance is provided by the TOE (e.g., fully satisfies the control, partially satisfies the
control). In addition, a comprehensive review of the specified assurance activities, and those
evaluation activities that occur as part of satisfying the SARs will be summarized to provide the
certification team information regarding how compliance was determined (e.g., document review,
vendor assertion, degree of testing/verification). This information will indicate to the certification
team what, if any, additional activities they need to perform to determine the degree of compliance
to specified controls.
Since the ST will make choices as far as selections, and will be filling in assignments, a final story
cannot necessarily be made until the ST is complete and evaluated. Therefore, this information
should be included in the ST in addition to the PP. Additionally, there may be some necessary
interpretation (e.g.,“modification”) to the activities performed by the evaluator based on a specific
implementation. The scheme could have the oversight personnel (e.g., Validators) fill in this type of
information, or could have this done by the evaluator as part of the assurance activities. The
verification activities are a critical piece of information that must be provided so the certification
team can determine what, if anything, they need to do in addition to the work of the evaluation
team.
Identifier
Name
AC-3
AC-6
AC-8
AC-11
AC-14
AC-17(7)
AU-2
AU-2(4)
AU-3
AU-3(1)
Access Enforcement
Least Privilege
System use Notification
Session Lock
Permitted Actions Without Identification
Remote Access
Auditable Events
AU-8
AU-10
AU-12
IA-2
IA-5
IA-6
Applicable SFRs
Content of Audit Records
Time Stamps
Non-Repudiation
Audit Generation
Identification and Authentication
Authenticator Management
Authenticator Feedback
FMT_MTD.1
FMT_MTD.1
FTA_TAB.1
FTA_SSL_EXT.1
FIA_UIA_EXT.1
FCS_SSH_EXT.1
FAU_GEN.1
FAU_GEN.1
FAU_GEN.1, FAU_GEN.2
FAU_GEN.1
FPT_STM.1
FCS_COP.1(2)
FAU_GEN.1
FIA_UIA_EXT.1
FIA_PMG_EXT.1
FIA_UAU.7
46
Identifier
Name
Applicable SFRs
SC-4
Information in Shared Resources
FDP_RIP.2
SC-8
Transmission Integrity
SC-9
Transmission Confidentiality
SC-10
SC-11
SC-12
Network Disconnect
Trusted Path
Cryptographic Key Establishment and
Management
Security Functionality Verification
FCS_IPSEC_EXT.1, FCS_TLS_EXT.1,
FCS_HTTPS_EXT.1, FCS_SSH_EXT.1, FPT_ITT.1(2),
FTP_ITC.1
FCS_IPSEC_EXT.1, FCS_TLS_EXT.1,
FCS_HTTPS_EXT.1, FCS_SSH_EXT.1, FPT_ITT.1(1),
FTP_ITC.1
FTA_SSL.3
FTP_TRP.1
FCS_CKM.1, FCS_CKM_EXT.4
SI-6
FPT_TST_EXT.1
47
ANNEX C: ADDITIONAL REQUIREMENTS
As indicated in the body of this PP, there are several methods by which conformant TOEs can
mitigate threats against compromise of the communication channel between administrators, other
portions of the (distributed) TOE, or external IT entities. One of the secure communication
protocols (IPSEC, SSH, TLS, TLS/HTTPS) must be implemented in order to provide protected
connectivity for (at a minimum) the audit server and remote administrators. Since there are
requirements associated with each of the protocol suites, specification of the protocols in the PP
becomes confusing and problematic, since specification of optional requirements is not readily
supported by the CC. In order to address this situation as cleanly as possible, the following
requirements should be included in the ST depending on the selections for the FTP_ITC.1 and
FTP_TRP.1 components.
Additionally, distributed TOEs are allowed to claim conformance to this PP. In these cases, the
communications between the disparate parts of the TOE need to be protected, and so the ST
author includes the two FPT_ITT iterations in the main body of the ST.
Note that minor adjustments to the narrative information in the beginning of the ST may be
required depending on the selections performed. Additionally, depending on the requirements
selected, the appropriate information from Section C1.2 Auditable Events will need to be added to
the auditable events table in the ST.
C1.1 Requirements
FCS_IPSEC_EXT.1 Explicit: IPSEC
FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the
cryptographic algorithms AES-CBC-128, AES-CBC-256 (both specified by RFC 3602), [selection: no other
algorithms, AES-GCM-128, AES-GCM-256 as specified in RFC 4106], and using [selection, choose at least
one of: IKEv1 as defined in RFCs 2407, 2408, 2409, RFC 4109, and [selection: no other RFCs for hash
functions, RFC 4868 for hash functions]; IKEv2 as defined in RFCs 5996 (with mandatory support for NAT
traversal as specified in section 2.23), 4307, and [selection: no other RFCs for hash functions, RFC 4868
for hash functions]].
Application Note: The first selection is used to identify additional cryptographic algorithms
supported. Either IKEv1 or IKEv2 support must be provided, although conformant TOES can provide
both; the second selection is used to make this choice. For IKEv1, the requirement is to be
interpreted as requiring the IKE implementation conforming to RFC 2409 with the
additions/modifications as described in RFC 4109. RFC 4868 identifies additional hash functions for
use with both IKEv1 and IKEv2; if these functions are implemented, the third (for IKEv1) and fourth
(for IKEv2) selection can be used. IKEv2 will be required after January 1st, 2014.
FCS_IPSEC_EXT.1.2 The TSF shall ensure that IKEv1 Phase 1 exchanges use only main mode.
Assurance Activity:
48
The evaluator shall examine the TSS to verify that it describes how "confidentiality only" ESP mode is
disabled. The evaluator shall also examine the operational guidance to determine that it describes
any configuration necessary to ensure that "confidentiality only" mode is disabled, and that an
advisory is present indicating that tunnel mode is the preferred ESP mode since it protects the entire
packet.
The evaluator shall examine the TSS to ensure that, in the description of the IPsec protocol
supported by the TOE, it states that aggressive mode is not used for IKEv1 Phase 1 exchanges, and
that only main mode is used. If this requires configuration of the TOE prior to its operation, the
evaluator shall check the operational guidance to ensure that instructions for this configuration are
contained within that guidance. The evaluator shall also perform the following tests:

Test 1: The evaluator shall configure the TOE as indicated in the operational guidance,
and attempt to establish a connection using an IKEv1 Phase 1 connection in aggressive
mode. This attempt should fail. The evaluator should then show that main mode
exchanges are supported.

Test 2: The evaluator shall configure the TOE as indicated in the operational guidance,
and attempt to establish a connection using ESP in "confidentiality only" mode. This
attempt should fail. The evaluator shall then establish a connection using ESP in
confidentiality and integrity mode.
FCS_IPSEC_EXT.1.3 The TSF shall ensure that IKEv1 SA lifetimes are able to be limited to 24 hours
for Phase 1 SAs and 8 hours for Phase 2 SAs.
Application Note: The above requirement can be accomplished either by providing Security
Administrator-configurable lifetimes (with appropriate FMT requirements and instructions in
documents mandated by AGD_OPE, as necessary), or by “hard coding” the limits in the
implementation.
Assurance Activity:
The evaluator checks to ensure that the TSS describes how lifetimes for IKEv1 SAs (both Phase 1 and
Phase 2) are established. If they are configurable, then the evaluator verifies that the appropriate
instructions for configuring these values are included in the operational guidance. The evaluator
also performs the following test:

Test 1: The evaluator shall construct a test where a Phase 1 SA is established and
attempted to be maintained for more than 24 hours before it is renegotiated. The
evaluator shall observe that this SA is closed or renegotiated in 24 hours or less. If such
an action requires that the TOE be configured in a specific way, the evaluator shall
implement tests demonstrating that the configuration capability of the TOE works as
documented in the operational guidance.

Test 2: The evaluator shall perform a test similar to Test 1 for Phase 2 SAs, except that
the lifetime will be 8 hours instead of 24.
49
FCS_IPSEC_EXT.1.4 The TSF shall ensure that IKEv1 SA lifetimes are able to be limited to
[assignment: number between 100 - 200] MB of traffic for Phase 2 SAs.
Application Note: The above requirement can be accomplished either by providing Security
Administrator-configurable lifetimes (with appropriate FMT requirements and instructions in
documents mandated by AGD_OPE), or by “hard coding” the limits in the implementation. The ST
author selects the amount of data in the range specified by the requirement.
In general, instructions for setting the parameters of the implementation, including lifetime of the
SAs, should be specified through FMT requirements and included in the administrative guidance
generated for AGD_OPE.
Assurance Activity:
The evaluator checks to ensure that the TSS describes how lifetimes for IKEv1 Phase 2 SAs--with
respect to the amount of traffic that is allowed to flow using a given SA--are established. If the
value is configurable, then the evaluator verifies that the appropriate instructions for configuring
these values are included in the operational guidance. The evaluator also performs the following
test:

Test 1: The evaluator shall construct a test where a Phase 2 SA is established and
attempted to be maintained while more data than is specified in the above assignment
flows over the connection. The evaluator shall observe that this SA is closed or
renegotiated before the amount of data specified is exceeded. If such an action
requires that the TOE be configured in a specific way, the evaluator shall implement
tests demonstrating that the configuration capability of the TOE works as documented
in the operational guidance.
FCS_IPSEC_EXT.1.5 The TSF shall ensure that all IKE protocols implement DH Groups 14 (2048-bit
MODP), and [selection: 24 (2048-bit MODP with 256-bit POS), 19 (256-bit Random ECP), 20 (384-bit
Random ECP), [assignment: other DH groups that are implemented by the TOE], no other DH
groups].
Application Note: The above requires that the TOE support DH Group 14. If other groups are
supported, then those should be selected (for groups 24, 19, and 20) or specified in the assignment
above; otherwise “no other DH groups” should be selected. This applies to IKEv1 and (if
implemented) IKEv2 exchanges.
In future publications of this PP DH Groups 19 (256-bit Random ECP) and 20 (384-bit RandomECP)
will be required.
Assurance Activity:
The evaluator shall check to ensure that the DH groups specified in the requirement are listed as
being supported in the TSS. If there is more than one DH group supported, the evaluator checks to
50
ensure the TSS describes how a particular DH group is specified/negotiated with a peer. The
evaluator shall also perform the following test:

Test 1: For each supported DH group, the evaluator shall test to ensure that all IKE
protocols can be successfully completed using that particular DH group.
FCS_IPSEC_EXT.1.6 The TSF shall ensure that all IKE protocols implement Peer Authentication using
the [selection: DSA, rDSA, ECDSA] algorithm.
Application Note: The selected algorithm should correspond to an appropriate selection for
FCS_COP.1(2).
Assurance Activity:
The evaluator shall check that the TSS contains a description of the IKE peer authentication process
used by the TOE, and that this description covers the use of the signature algorithm or algorithms
specified in the requirement. The evaluator shall also perform the following test:

Test 1: For each supported signature algorithm, the evaluator shall test that peer
authentication using that algorithm can be successfully achieved.
FCS_IPSEC_EXT.1.7 The TSF shall support the use of pre-shared keys (as referenced in the RFCs) for
use in authenticating its IPsec connections.
Assurance Activity:
The evaluator shall check to ensure that the TSS describes how pre-shared keys are established and
used in authentication of IPsec connections. The evaluator shall check that the operational guidance
describes how pre-shared keys are to be generated and established for a TOE. The description in the
TSS and the operational guidance shall also indicate how pre-shared key establishment is
accomplished for both TOEs that can generate a pre-shared key as well as TOEs that simply use a
pre-shared key. The evaluator shall also perform the following test:

Test 1: The evaluator shall generate a pre-shared key and use it, as indicated in the
operational guidance, to establish an IPsec connection between two peers. If the TOE
supports generation of the pre-shared key, the evaluator shall ensure that
establishment of the key is carried out for an instance of the TOE generating the key as
well as an instance of the TOE merely taking in and using the key.
51
FCS_IPSEC_EXT.1.8 The TSF shall support the following:
1. Pre-shared keys shall be able to be composed of any combination of upper and lower
case letters, numbers, and special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”,
“&”, “*”, “(“, “)”, *assignment: other characters++;
2. Pre-shared keys of 22 characters and [selection: [assignment: other supported lengths],
no other lengths].
Application Note: The ST author selects the special characters that are supported by TOE; they may
optionally list additional special characters supported using the assignment. For the length of the
pre-shared keys, a common length (22 characters) is required to help promote interoperability. If
other lengths are supported they should be listed in the assignment; this assignment can also specify
a range of values (e.g., "lengths from 5 to 55 characters") as well.
Assurance Activity:
The evaluator shall check the operational guidance to ensure that it describes the generation of preshared keys, including guidance on generating strong keys and the allowed character set. The
evaluator shall check that this guidance does not limit the pre-shared key in a way that would not
satisfy the requirement. It should be noted that while the administrator (in contravention to the
operational guidance) can choose a key that does not conform to the requirement, there is no
requirement that the TOE check the key to ensure that it meets the rules specified in this component.
However, should the administrator choose to create a password that conforms to the rules above
(and the operational guidance); the TOE should not prohibit such a choice. The evaluator shall also
perform the following test; this may be combined with Test 1 for FCS_IPSEC_EXT.1.7:

Test 1: The evaluator shall generate a pre-shared key that is 22 characters long that
meets the composition requirements above. The evaluator shall then use this key to
successfully establish an IPsec connection. While the evaluator is not required to test
that all of the special characters or lengths listed in the requirement are supported, it is
required that they justify the subset of those characters chosen for testing, if a subset is
indeed used.
FCS_TLS_EXT.1 Explicit: TLS
FCS_TLS_EXT.1.1 The TSF shall implement one or more of the following protocols [selection: TLS 1.0
(RFC 2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246)] supporting the following ciphersuites:
Mandatory Ciphersuites:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
52
Optional Ciphersuites:
[selection:
None
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_ SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
].
Application Note: The ST author must make the appropriate selections and assignments to reflect
the TLS implementation. The ST author must provide enough detail to determine how the
implementation is complying with the standard(s) identified; this can be done either by adding
elements to this component, or by additional detail in the TSS.
The ciphersuites to be used in the evaluated configuration are limited by this requirement. The ST
author should select the optional ciphersuites that are supported; if there are no ciphersuites
supported other than the mandatory suites, then “None” should be selected. If administrative steps
need to be taken so that the suites negotiated by the implementation are limited to those in this
requirement, the appropriate instructions need to be contained in the guidance called for by
AGD_OPE.
The Suite B algorithms (RFC 5430) listed above are the preferred algorithms for implementation.
Since the Dec. 2010 publication of NDPP v1.0, there has been limited progress with respect to
extending the prevalence of TLS 1.2 support in commercial network devices. Future publications of
this PP will require support for TLS 1.2 (RFC 5246); however, it is likely that an NDPP v2.0 will be
published in late 2012 which will not include a requirement for TLS 1.2 support, but will require that
the TOE offer a means to deny all connection attempts using SSL 2.0 or SSL 3.0.
Assurance Activity:
The evaluator shall check the description of the implementation of this protocol in the TSS to ensure
that optional characteristics (e.g., extensions supported, client authentication supported) are
specified, and the ciphersuites supported are specified as well. The evaluator shall check the TSS to
ensure that the ciphersuites specified are identical to those listed for this component. The evaluator
shall also check the operational guidance to ensure that it contains instructions on configuring the
TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites
advertised by the TOE may have to be restricted to meet the requirements). The evaluator shall also
perform the following test:

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites
specified by the requirement. This connection may be established as part of the
establishment of a higher-level protocol, e.g., as part of a HTTPS session. It is sufficient
53
to observe (on the wire) the successful negotiation of a ciphersuite to satisfy the intent
of the test; it is not necessary to examine the characteristics of the encrypted traffic in
an attempt to discern the ciphersuite being used (for example, that the cryptographic
algorithm is 128-bit AES and not 256-bit AES).
FCS_SSH_EXT.1 Explicit: SSH
FCS_SSH_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252,
4253, and 4254.
Application Note: The ST author must provide enough detail to determine how the implementation
is complying with the standard(s) identified; this can be done either by adding elements to this
component, or by additional detail in the TSS.
In the next version of this PP, a requirement will be added regarding rekeying. The requirement will
read “The TSF shall ensure that the SSH connection be rekeyed after no more than 2 28 packets have
been transmitted using that key.”
FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following
authentication methods as described in RFC 4252: public key-based, password-based.
Assurance Activity:
The evaluator shall check to ensure that the TSS contains a description of the public key algorithms
that are acceptable for use for authentication, that this list conforms to FCS_SSH_EXT.1.5, and
ensure that password-based authentication methods are also allowed. The evaluator shall also
perform the following tests:

Test 1: The evaluator shall, for each public key algorithm supported, show that the TOE
supports the use of that public key algorithm to authenticate a user connection. Any
configuration activities required to support this test shall be performed according to
instructions in the operational guidance.

Test 2: Using the operational guidance, the evaluator shall configure the TOE to accept
password-based authentication, and demonstrate that a user can be successfully
authenticated to the TOE over SSH using a password as an authenticator.
FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than
[assignment: number of bytes] bytes in an SSH transport connection are dropped.
Application Note: RFC 4253 provides for the acceptance of “large packets” with the caveat that the
packets should be of “reasonable length” or dropped. The assignment should be filled in by the ST
author with the maximum packet size accepted, thus defining “reasonable length” for the TOE.
54
Assurance Activity:
The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are
detected and handled. The evaluator shall also perform the following test:

Test 1: The evaluator shall demonstrate that if the TOE receives a packet larger than
that specified in this component, that packet is dropped.
FCS_SSH_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms: AES-CBC-128, AES-CBC-256, [selection: AEAD_AES_128_GCM,
AEAD_AES_256_GCM, no other algorithms].
Application Note: In the assignment, the ST author can select the AES-GCM algorithms, or "no other
algorithms" if AES-GCM is not supported. If AES-GCM is selected, there should be corresponding
FCS_COP entries in the ST. Since the Dec. 2010 publication of NDPP v1.0, there has been consider
progress with respect to the prevalence of AES-GCM support in commercial network devices. It is
likely that an NDPP v2.0 will be published in late 2012 which will require AES-GCM and AES-CBC will
become optional.
Assurance Activity:
The evaluator shall check the description of the implementation of this protocol in the TSS to ensure
that optional characteristics are specified, and the encryption algorithms supported are specified as
well. The evaluator shall check the TSS to ensure that the encryption algorithms specified are
identical to those listed for this component. The evaluator shall also check the operational guidance
to ensure that it contains instructions on configuring the TOE so that SSH conforms to the
description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be
restricted to meet the requirements). The evaluator shall also perform the following test:

Test 1: The evaluator shall establish a SSH connection using each of the encryption
algorithms specified by the requirement. It is sufficient to observe (on the wire) the
successful negotiation of a protocol to satisfy the intent of the test.
FCS_SSH_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses SSH_RSA and
[selection: PGP-SIGN-RSA, PGP-SIGN-DSS, no other public key algorithms,] as its public key
algorithm(s).
Application Note: RFC 4253 specifies required and allowable public key algorithms. This requirement
makes SSH-RSA “required” and allows two others to be claimed in the ST. The ST author should
make the appropriate selection, selecting "no other public key algorithms" if only SSH_RSA is
implemented.
Assurance Activity:
The assurance activity associated with FCS_SSH_EXT.1.4 verifies this requirement.
55
FCS_SSH_EXT.1.6 The TSF shall ensure that data integrity algorithms used in SSH transport
connection is [selection: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96].
Assurance Activity:
The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and
that that list corresponds to the list in this component. The evaluator shall also check the
operational guidance to ensure that it contains instructions to the administrator on how to ensure
that only the allowed data integrity algorithms are used in SSH connections with the TOE
(specifically, that the “none” MAC algorithm is not allowed).
FCS_SSH_EXT.1.7 The TSF shall ensure that diffie-hellman-group14-sha1 is the only allowed key
exchange method used for the SSH protocol.
Assurance Activity:
The evaluator shall ensure that operational guidance contains configuration information that will
allow the security administrator to configure the TOE so that all key exchanges for SSH are
performed using DH group 14. If this capability is “hard-coded” into the TOE, the evaluator shall
check the TSS to ensure that this is stated in the discussion of the SSH protocol. The evaluator shall
also perform the following test:

Test 1: The evaluator shall attempt to perform a diffie-hellman-group1-sha1 key
exchange, and observe that the attempt fails. The evaluator shall then attempt to
perform a diffie-hellman-group14-sha1 key exchange, and observe that the attempt
succeeds.
FCS_HTTPS_EXT.1 Explicit: HTTPS
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818.
Application Note: The ST author must provide enough detail to determine how the implementation
is complying with the standard(s) identified; this can be done either by adding elements to this
component, or by additional detail in the TSS.
FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS as specified in FCS_TLS_EXT.1.
Assurance Activity:
The evaluator shall check the TSS to ensure that it is clear on how HTTPS uses TLS to establish an
administrative session, focusing on any client authentication required by the TLS protocol vs. security
administrator authentication which may be done at a different level of the processing stack. Testing
for this activity is done as part of the TLS testing; this may result in additional testing if the TLS tests
are done at the TLS protocol level.
56
FPT_ITT.1
Basic Internal TSF Data Transfer Protection
FPT_ITT.1.1
Refinement: The TSF shall protect TSF data from disclosure and detect its
modification when it is transmitted between separate parts of the TOE
through the use [selection, choose at least one of: IPsec, SSH, TLS,
TLS/HTTPS].
Application Note:
This requirement ensures all communications between components of a distributed TOE is protected
through the use of an encrypted communications channel. The data passed in this trusted
communication channel are encrypted as defined the protocol chosen in the first selection. The ST
author chooses the mechanism or mechanisms supported by the TOE, and then ensures the detailed
requirements in Annex C corresponding to their selection are copied to the ST if not already present.
Assurance Activity:
The evaluator shall examine the TSS to determine that the methods and protocols used to protect
distributed TOE components are described. The evaluator shall also confirm that all protocols listed
in the TSS in support of TOE administration are consistent with those specified in the requirement,
and are included in the requirements in the ST. The evaluator shall confirm that the operational
guidance contains instructions for establishing the communication paths for each supported
method. The evaluator shall also perform the following tests:

Test 1: The evaluators shall ensure that communications using each specified (in the
operational guidance) communications method is tested during the course of the
evaluation, setting up the connections as described in the operational guidance and
ensuring that communication is successful.

Test 2: The evaluator shall ensure, for each method of communication, the channel
data is not sent in plaintext.

Test 3: The evaluator shall ensure, for each method of communication, modification
of the channel data is detected by the TOE.
Further assurance activities are associated with the specific protocols.
C1.2 Auditable Events
Depending on the specific requirements selected by the ST author from Section C1.1, the ST author
should include the appropriate auditable events in the corresponding table in the ST for the
requirements selected.
Requirement
FCS_IPSEC_EXT.1
Auditable Events
Failure to establish an IPsec SA.
Additional Audit Record Contents
Reason for failure.
FCS_TLS_EXT.1
Establishment/Termination of an
IPsec SA.
Failure to establish a TLS Session.
Non-TOE endpoint of connection (IP address)
for both successes and failures.
Reason for failure.
Establishment/Termination of a TLS
Non-TOE endpoint of connection (IP address)
57
session.
for both successes and failures.
FCS_SSH_EXT.1
Failure to establish an SSH session
Reason for failure
FCS_HTTPS_EXT.1
Establishment/Termination of an
SSH session
Failure to establish a HTTPS Session.
Non-TOE endpoint of connection (IP address)
for both successes and failures.
Reason for failure.
FPT_ITT.1(1)
Establishment/Termination of a
HTTPS session.
None
Non-TOE endpoint of connection (IP address)
for both successes and failures.
None
FPT_ITT.1(2)
None
None
Application Note:
Auditing session establishment failures is highly dependent on the implementation and is currently
not standardized in the industry. In this version of the PP, no specific list or types of such failures is
mandated as being auditable. If a clear set of auditable events emerges as “standard” in evaluated
products then future versions of this PP will be more specific in terms of the exact protocol failures
that need to be auditable.
Assurance Activities:
The evaluator shall check to ensure that the TSS contains a list (possibly empty except for
authentication failures for user-level connections) of the protocol failures that are auditable. The
evaluator shall test all identified audit events during protocol testing/audit testing.
ANNEX D: ENTROPY DOCUMENTATION AND ASSESSMENT
The documentation of the entropy source should be detailed enough that, after reading, the
evaluator will thoroughly understand the entropy source and why it can be relied upon to provide
entropy. This documentation should include multiple detailed sections: design description, entropy
justification, operating conditions, and health testing. This documentation is not required to be
part of the TSS.
Design Description
Documentation shall include the design of the entropy source as a whole, including the interaction
of all entropy source components. It will describe the operation of the entropy source to include
how it works, how entropy is produced, and how unprocessed (raw) data can be obtained from
within the entropy source for testing purposes. The documentation should walk through the
entropy source design indicating where the random comes from, where it is passed next, any postprocessing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output
58
from the entropy source. Any conditions placed on the process (e.g., blocking) should also be
described in the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy
source and a description of how the security boundary ensures that an adversary outside the
boundary cannot affect the entropy rate.
Entropy Justification
There should be a technical argument for where the unpredictability in the source comes from and
why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of
the probability distribution and justification for that distribution given the particular source is one
way to describe this). This argument will include a description of the expected entropy rate and
explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process.
This discussion will be part of a justification for why the entropy source can be relied upon to
produce bits with entropy.
Operating Conditions
Documentation will also include the range of operating conditions under which the entropy source
is expected to generate random data. It will clearly describe the measures that have been taken in
the system design to ensure the entropy source continues to operate under those conditions.
Similarly, documentation shall describe the conditions under which the entropy source is known to
malfunction or become inconsistent. Methods used to detect failure or degradation of the source
shall be included.
Health Testing
More specifically, all entropy source health tests and their rationale will be documented. This will
include a description of the health tests, the rate and conditions under which each health test is
performed (e.g., at startup, continuously, or on-demand), the expected results for each health test,
and rationale indicating why each test is believed to be appropriate for detecting one or more
failures in the entropy source.
59