Motorola ST v1.5

Motorola WS5100 Wireless Switch and RFS7000 RF Switch
Security Target
Version 1.5
Motorola WS5100 Wireless Switch and RFS7000 RF Switch Security Target
TABLE OF CONTENTS
SECTION PAGE
1 Introduction to the Security Target ....................................................................... 6

1.1 Security Target Identification.....................................................................................6
1.2 Security Target Overview ...........................................................................................6
1.3 Common Criteria Conformance .................................................................................6
1.4 Conventions ................................................................................................................6
2 TOE Description...................................................................................................... 8
2.1 Overview......................................................................................................................8
2.2 TOE Hardware ...........................................................................................................10
2.3 Scope of Evaluation..................................................................................................10
2.4 IT Environment..........................................................................................................11
3 TOE Security Environment .................................................................................. 12
3.1 Secure Usage Assumptions.....................................................................................12
3.2 Threats to Security ...................................................................................................12
3.3 Organizational Security Policies..............................................................................14
4 Security Objectives .............................................................................................. 15
4.1 Security Objectives for the TOE ..............................................................................15
4.2 Security Objectives for the Environment ................................................................16
5 IT Security Requirements .................................................................................... 18
5.1 Strength of Function Claims ....................................................................................18
5.2 TOE Security Functional Requirements..................................................................18
5.2.1 Security Audit .......................................................................................................................... 20
5.2.1.1 FAU_GEN.1(1) Audit data generation .................................................................................... 20
5.2.1.2 FAU_GEN.2 User identity association .................................................................................... 23
5.2.1.3 FAU_SEL.1 Selective audit..................................................................................................... 23
5.2.1.4 FCS_BCM_EXP.1 Explicit: baseline cryptographic module ................................................... 23
5.2.1.5 FCS_CKM.1 Cryptographic key generation............................................................................ 23
5.2.1.6 FCS_CKM_EXP.2 Explicit: cryptographic key establishment................................................. 23
5.2.1.7 FCS_CKM.4 Cryptographic key destruction ........................................................................... 24
5.2.1.8 FCS_COP_EXP.1 Explicit: random number generation ......................................................... 24
5.2.1.9 FCS_COP_EXP.2(1) Explicit: cryptographic operation .......................................................... 24
5.2.1.10 FCS_COP_EXP.2(2) Explicit: cryptographic operation .......................................................... 24
5.2.1.11 FDP_PUD_EXP.1 Protection of user data .............................................................................. 25
5.2.1.12 FDP_RIP.1(1) Subset residual information protection ............................................................ 25
5.2.1.13 FIA_AFL.1(1) Administrator authentication failure handling ................................................... 25
5.2.1.14 FIA_ATD.1(1) Administrator attribute definition ...................................................................... 25
5.2.1.15 FIA_UAU.1 Timing of local authentication .............................................................................. 26
5.2.1.16 FIA_UAU_EXP.5(1) Explicit: multiple authentication mechanisms......................................... 26
5.2.1.17 FIA_UID.2 User identification before any action ..................................................................... 26
Page 2 of 85
5.2.1.18 FIA_USB.1(1) User-subject binding. ....................................................................................... 26
5.2.1.19 FIA_USB.1(2) User-subject binding. ....................................................................................... 27
5.2.1.20 FMT_MOF.1(1) Management of cryptographic security functions behavior........................... 27
5.2.1.21 FMT_MOF.1(2) Management of audit security functions behavior......................................... 27
5.2.1.22 FMT_MOF.1(3) Management of authentication security functions behavior .......................... 28
5.2.1.23 FMT_MSA.2 Secure security attributes .................................................................................. 28
5.2.1.24 FMT_MTD.1(1) Management of Audit pre-selection data ...................................................... 28
5.2.1.25 FMT_MTD.1(2) Management of authentication data (administrator)...................................... 28
5.2.1.26 FMT_SMF.1(1) Specification of management functions (cryptographic function) .................. 28
5.2.1.27 FMT_SMF.1(2) Specification of management functions (TOE audit record generation)........ 28
5.2.1.28 FMT_SMF.1(3) Specification of management functions (cryptographic key data) ................. 29
5.2.1.29 FMT_SMR.1(1) Security roles................................................................................................. 29
5.2.1.30 FPT_RVM.1(1) Non-bypassability of the TOE Security Policy (TSP) ..................................... 29
5.2.1.31 FPT_SEP.1(1) TSF domain separation .................................................................................. 29
5.2.1.32 FPT_STM_EXP.1 Reliable time stamps ................................................................................. 29
5.2.1.33 FPT_TST_EXP.1 TSF testing ................................................................................................. 29
5.2.1.34 FPT_TST_EXP.2 TSF testing of cryptographic modules........................................................ 30
5.2.1.35 FTA_SSL.3 TSF-initiated termination ..................................................................................... 30
5.2.1.36 FTA_TAB.1 Default TOE access banners .............................................................................. 30
5.2.1.37 FTP_ITC_EXP.1(1) Inter-TSF trusted channel ....................................................................... 30
5.2.1.38 FTP_TRP.1 Trusted path ........................................................................................................ 31
5.3 Security Requirements for the IT Environment. .....................................................31
5.3.1.1 FAU_GEN.1(2) Audit data generation .................................................................................... 32
5.3.1.2 FAU_SAR.1 Audit review ........................................................................................................ 34
5.3.1.3 FAU_SAR.2 Restricted audit review ....................................................................................... 34
5.3.1.4 FAU_SAR.3 Selectable audit review....................................................................................... 34
5.3.1.5 FAU_STG.1 Protected audit trail storage ............................................................................... 34
5.3.1.6 FAU_STG.3 Action in case of possible audit data loss........................................................... 35
5.3.1.7 FDP_RIP.1(2) Subset residual information protection ............................................................ 35
5.3.1.8 FIA_AFL.1(2) Remote user authentication failure handling .................................................... 35
5.3.1.9 FIA_ATD.1(2) User attribute definition .................................................................................... 35
5.3.1.10 FIA_UAU_EXP.5(2) Remote authentication mechanisms ...................................................... 35
5.3.1.11 FIA_UID.1 Timing of identification........................................................................................... 36
5.3.1.12 FMT_SMF.1(4) Specification of management functions (user identification and authentication)
36
5.3.1.13 FMT_SMF.1(5) Specification of management functions (time stamps).................................. 36
5.3.1.14 FMT_MOF.1(4) Management of security functions behavior ................................................. 36
5.3.1.15 FMT_MTD.1(3) Management of identification data (user) ...................................................... 36
5.3.1.16 FMT_MTD.1(4) Management of authentication data (user) ................................................... 36
5.3.1.17 FMT_MTD.1(5) Management of time data.............................................................................. 37
5.3.1.18 FMT_SMR.1(2) Security roles................................................................................................. 37
5.3.1.19 FTP_ITC_EXP.1(2) Inter-TSF trusted channel ....................................................................... 37
5.3.1.20 FPT_RVM.1(2) Non-bypassability of the IT Environment Security Policy (TSP).................... 37
5.3.1.21 FPT_SEP.1(2) TSF domain separation .................................................................................. 37
5.3.1.22 FPT_STM.1 Reliable time stamps .......................................................................................... 37
5.4 TOE Security Assurance Requirements..................................................................38
6 TOE Summary Specification................................................................................ 40
6.1 TOE Security Functions ...........................................................................................40
6.1.1 Security Audit .......................................................................................................................... 40
6.1.2 Cryptographic Support ............................................................................................................ 41
6.1.3 User Data Protection ............................................................................................................... 41
6.1.4 Identification and Authentication ............................................................................................. 41
6.1.5 Security Management ............................................................................................................. 42
Page 3 of 85
6.1.6 Protection of the TSF .............................................................................................................. 42
6.1.7 TOE Access ............................................................................................................................ 43
6.1.8 Trusted Path/Channels ........................................................................................................... 43
6.2 Assurance Measures ................................................................................................43
7 PP Claims .............................................................................................................. 46
8 Rationale ............................................................................................................... 47
8.1 Rationale for Security Objectives ............................................................................47
8.2 Rationale for Security Objectives in the TOE Environment ...................................60
8.3 Rationale for TOE Security Requirements ..............................................................61
8.4 Rationale for TOE IT Environment Security Requirements....................................70
8.5 Rationale for Assurance Requirements ..................................................................74
8.6 Satisfaction of Dependencies ..................................................................................74
8.7 Rationale for Strength of Function Claims..............................................................75
8.8 Rationale for Explicit requirements .........................................................................75
8.9 TOE Summary Specification Rationale ...................................................................78
8.10 PP Claims Rationale .................................................................................................83
9 Appendix ............................................................................................................... 84
Page 4 of 85
Table of Tables
Table Page
Table 3-1 TOE Assumptions ...............................................................................................................................................12

Table 3-2 Threats................................................................................................................................................................13
Table 3-3 Organizational Security Policies........................................................................................................................14
Table 4-1 Security Objectives for TOE...............................................................................................................................15
Table 4-2 Security Objectives for the IT and Non IT Environment ....................................................................................16
Table 5-1 Functional Components .....................................................................................................................................18
Table 5-2 TOE Auditable Events ........................................................................................................................................21
Table 5-3 Functional Components .....................................................................................................................................31
Table 5-4 TOE IT Environment Auditable Events ..............................................................................................................32
Table 5-5 Assurance Components ......................................................................................................................................38
Table 6-1 Assurance Measures...........................................................................................................................................43
Table 8-1 Security Objectives to Threats and Policies Mappings ......................................................................................47
Table 8-2 Rationale for TOE Security Requirements .........................................................................................................61
Table 8-3 Rationale for Requirements on the TOE IT Environment ..................................................................................70
Table 8-4 Rationale for Explicit Requirements ..................................................................................................................75
Table 8-5 Mapping of Security Functions to TSFRs...........................................................................................................78
Table 8-6 Suitability of Security Functions to meet TSFRs ................................................................................................80
Table 9-1 Abbreviations and Acronyms..............................................................................................................................84
Table 9-2 References ..........................................................................................................................................................84
Document History
Revision Date Comment

1.0 3/5/2007 Initial Revision
1.1 4/11/2007 Minor improvements
1.2 9/10/2007 Addressed observation reports
1.3 2/5/2008 Addressed validator comments
1.4 04/14/2009 Minor corrections
1.5 05/20/09 Minor improvement
Page 5 of 85
1 Introduction to the Security Target
1.1 Security Target Identification
TOE Identification:
This Security Target describes two TOEs:
Motorola WS5100 Wireless Switch

Hardware Version: WS5100
Software Version: WS5100-3.0.0.0-022GR
Motorola RFS7000 RF Switch

Hardware Version: RFS7000
Software Version: RFS7000-1.0.0.0-022GR
Document Title: Motorola WS5100 Wireless Switch and RFS7000 RF Switch Security Target,
Document Version 1.5, May 20, 2009
CC Version: Common Criteria Version 2.3
Assurance Level: EAL4 augmented with ALC_FLR.2
Strength of Function: SOF-basic
Protection Profile: US Government Wireless Local Area Network (WLAN) Access System
Protection Profile for Basic Robustness Environments, Version 1.0, April
2006.
1.2 Security Target Overview

This Security Target (ST) describes Motorola WS5100 Wireless Switch and RFS7000 RF Switch
devices. A wireless switch is a hardware device used to control operation of multiple wireless
access points and to provide secure Wireless Local Area Network (WLAN) connectivity to a set of
wireless client devices.
1.3 Common Criteria Conformance

CC Part 2 extended, Part 3 conformant, and meets the requirements of Evaluation Assurance Level
(EAL) 4 from the Common Criteria Version 2.3 augmented with ALC.FLR.2 (Flaw Remediation).
Conformant to US Government Wireless Local Area Network (WLAN) Access System Protection
Profile for Basic Robustness Environments, Version 1.0, April 2006.
1.4 Conventions
The notation, formatting, and conventions used in this ST are consistent with version 2.3 of the
Common Criteria (CC).
Page 6 of 85
The CC allows several operations to be performed on functional requirements; refinement,
selection, assignment, and iteration are defined in paragraph 2.1.4 of Part 2 of the CC. Each of
these operations is used in this ST.
The refinement operation is used to add detail to a requirement, and thus further restricts a
requirement. Refinement of security requirements is denoted by bold text. Deleted words are
denoted by strike-through text.
The selection operation is used to select one or more options provided by the CC in stating a
requirement. Selections are denoted by italicized text.
The assignment operation is used to assign a specific value to an unspecified parameter, such as
the length of a password. Assignment is indicated by showing the value in square brackets,
[Assignment_value].
The iteration operation is used when a component is repeated with varying operations. Iteration is
denoted by showing the iteration number in parenthesis following the component identifier,
(iteration_number).
The CC paradigm also allows protection profile (PP) and security target authors to create their own
requirements. Such requirements are termed ‘explicit requirements’ and are permitted if the CC
does not offer suitable requirements to meet the authors’ needs. Explicit requirements must be
identified and are required to use the CC class/family/component model in articulating the
requirements. In this ST, explicit requirements will be indicated with the “EXP” following the
component name.
Application Notes are provided to help the developer, either to clarify the intent of a requirement,
identify implementation choices, or to define “pass-fail” criteria for a requirement. For those
components where Application Notes are appropriate, the Application Notes will follow the
requirement component.
Assumptions: TOE security environment assumptions are given names beginning with “A.”-- e.g.,
A.ADMINISTRATION.
Threats: TOE security environment threats are given names beginning with “T.”-- e.g.,
T.SIGNAL_DETECT.
Policies: TOE security environment policies are given names beginning with “P.”—e.g.,
P.GUIDANCE.
Objectives: Security objectives for the TOE and the TOE environment are given names beginning
with “O.” and “OE.”, respectively,—e.g., O.ACCESS and OE.ADMIN.
Page 7 of 85
2 TOE Description
2.1 Overview
This Security Target describes two TOEs which have the same security functionality, but different
performance and hardware characteristics.
Motorola WS5100 Wireless Switch is a rack-mounted hardware device with 1U chassis. It supports
up to 48 wireless access points. The device includes two Gigabit Ethernet ports, which provide
network connectivity. An RS232 Serial port is used for local administration.
Figure 1. Motorola WS5100 Wireless Switch
Motorola RFS7000 RF Switch is a rack-mounted hardware device with 1U chassis. It supports up to

256 wireless access points. The device includes 8 Gigabit Ethernet ports and one 100Mbit Ethernet
port, which provide network connectivity. An RJ45 Serial port is used for local administration. One
CompactFlash card slot, two USB ports, and the 100Mbit Ethernet port are not used and are
covered by a tamper evident label at the factory.
Figure 2. Motorola RFS7000 RF Switch
In the following, both devices are referred to as “the TOE”.
Page 8 of 85
Figure 3. Typical TOE deployment diagram
TOE Audit Auth Time

server Server Server
Local
Admin IPSec/VPN tunnel
L2
Switch
The TOE is a device used to control operation of multiple wireless access points and to provide
secure Wireless Local Area Network (WLAN) connectivity to a set of wireless client devices. The
TOE is installed at a wired network location, and is logically connected to a set of wireless access
point devices over a wired Ethernet network. Wireless access point devices are hardware radio
devices, which do not provide security functionalities and are used to tunnel wireless network traffic
between the TOE and wireless client devices.
The TOE protects data exchanged with wireless client devices using IEEE 802.11i wireless security
protocol, which provides data authentication and encryption using the AES-CCM cryptographic
algorithm. The TOE uses FIPS 140-2 compliant cryptographic implementations for all cryptographic
purposes and is operated in the FIPS 140-2 approved mode of operation.
Wireless users are required to authenticate before access to the wired network is granted by the
TOE. The authentication is based on IEEE 802.1X EAP-TLS, EAP-TTLS and PEAP authentication
protocols. The TOE acts as the 802.1X authenticator and utilizes services of an external RADIUS
authentication server to provide wireless user authentication. During the authentication phase the
TOE serves as an intermediary passing authentication messages between the wireless client
device and the external authentication server. If the authentication is successful, the authentication
server passes to the TOE 802.11i session keys used to establish a 802.11i secure connection
Page 9 of 85
between the TOE and the wireless client device. Once the connection is established, the wireless
client device may access the protected wired network utilizing the TOE as a gateway. The network
connection between the TOE and the external authentication server is protected using the
IPSec/IKE security protocol. EAP-TLS authentication protocol uses a client certificate for wireless
user authentication, EAP-TTLS and PEAP protocols use password-based authentication.
The TOE provides remote management capabilities using SSH security protocol, as well as local
management capabilities via a local serial port connection. The TOE administrators are required to
authenticate using a username/password combination. The TOE provides an option to authenticate
administrators against an internal administrator database, or against the external authentication
server, however only internal administrator database is used in the evaluated configuration.
The TOE provides capabilities to terminate idle wireless user and administrator sessions after the
inactivity time limit has been reached, as well as disable a remote administrator account after a pre-
defined number of failed authentication attempts had been reached. The account can then be re-
enabled using a local serial port administration session.
The TOE provides auditing capabilities which utilize services of an external syslog audit server. The
network connection between the TOE and the external audit server is secured using IPSec/IKE
security protocol.
The TOE utilizes services of an external Network Time Protocol (NTP) server to obtain reliable time
stamps used in audit records. The network connection between the TOE and the external NTP
server is secured using IPSec/IKE security protocol.
The TOE provides capabilities to run a set of self-tests on power-on and on demand to verify the
integrity and critical functions of the TOE. The security of network data is maintained by zeroizing
the memory location corresponding to a network packet, after the packet has been processed by
the TOE.
2.2 TOE Hardware
The TOE is a standalone rack-mounted hardware device, which includes a set of general-purpose
and network processors that execute the TOE software, as well as volatile and non-volatile storage
components. The physical boundary of the TOE is composed of a metal and hard plastic case and
meets the physical security requirements of FIPS 140-2 at Security Level 2. Tamper-evident seals
are applied to the TOE enclosure to satisfy the tamper evidence requirements of the FIPS 140-2
standard at Security Level 2.
The TOE physical boundary includes a set of network Ethernet ports used to provide network
connectivity, a serial console port used for local administration, a set of status LEDs as well as a
power port used to provide a source of external electric power.
2.3 Scope of Evaluation
The identification of the TOE is provided in Section 1.1 “Security Target Identification”. The scope of
evaluation is comprised by evaluation of TOE security functions specified in Section 6.1 of this
document.
Page 10 of 85
The following wireless security protocols are disabled in the FIPS 140-2 mode of operation and are
not included in this evaluation: WEP, WPA, TKIP.
The following TOE features are not included in the evaluation: intrusion detection, protection
against denial-of-service attacks, roaming of mobile clients across distributed networks, stateful
packet analysis, network address translation, 802.11 traffic prioritization and precedence, Wi-Fi
multimedia extensions.
2.4 IT Environment
As described in Section 2.1 the TOE uses services of an external RADIUS authentication server for
user authentication. The authentication server supports EAP-TLS, EAP-TTLS and PEAP
authentication protocols.
Reliable time stamps are provided by an external Network Time Protocol (NTP) server.
Audit records generated by the TOE are transmitted to the external syslog audit server. The audit
server provides protected storage for audit records, as well as a capability to view and search audit
records.
Network connections between the TOE and external authentication, audit and time servers are
protected by a trusted channel, as required by the WLANAS PP. The IPSec/IKE security protocol is
used to establish secure network connections for the trusted channel.
Page 11 of 85
3 TOE Security Environment

This section describes the assumptions, threats, and policies that are relevant to both the TOE and
the TOE environment.
3.1 Secure Usage Assumptions

Assumptions are limiting conditions that are accepted before developing policy or considering
threats. Table 3-1 TOE Assumptions identifies the conditions that are assumed to exist in the
operational environment. The TOE Assumptions are identical to those of WLANAS PP.
Table 3-1 TOE Assumptions
Name Assumption
A.NO_EVIL Administrators are non-hostile, appropriately trained and follow all
administrator guidance.
A.NO_GENERAL_PURPOSE There are no general-purpose computing or storage repository
capabilities (e.g., compilers, editors, or user applications) available
on the TOE.
A.PHYSICAL Physical security, commensurate with the value of the TOE and the
data it contains, is assumed to be provided by the environment
A.TOE_NO_BYPASS Wireless clients are configured so that information cannot flow
between a wireless client and any other wireless client or host
networked to the TOE without passing through the TOE.
3.2 Threats to Security
Threats are actions that may have an adverse affect on the TOE. Exposure of wireless
communications in the RF transmission environment introduces unique threats for the WLAN. The
WLAN interconnected to a wired network could effectively create a hole in the wired infrastructure
boundary because it exposes information to the RF medium where signals can be more readily
detected and intercepted. With WLANs, an adversary no longer requires physical access to the
network to exploit a wireless system. For basic robustness, the threats identified do not include
those that would be considered a sophisticated attack (e.g., intentional jamming, traffic analysis)
The TOE must counter the following threats to security. The threats to security are identical to those
of WLANAS PP.
Page 12 of 85
Table 3-2 Threats
Name Threat Definition

T.ACCIDENTAL_ADMIN_ ERROR An administrator may incorrectly install or configure the TOE
resulting in ineffective security mechanisms.
T.ACCIDENTAL_ CRYPTO_ A user or process may cause key, data or executable code
COMPROMISE associated with the cryptographic functionality to be
inappropriately accessed (viewed, modified, or deleted), thus
compromising the cryptographic mechanisms and the data
protected by those mechanisms.
T.MASQUERADE
A user or process may masquerade as another entity in order
to gain unauthorized access to data or TOE resources.
T.POOR_DESIGN
Unintentional errors in requirements specification or design of
the TOE may occur, leading to flaws that may be exploited by
a casually mischievous user or program.
T.POOR_IMPLEMENTATION Unintentional errors in implementation of the TOE design may

occur, leading to flaws that may be exploited by a casually
mischievous user or program.
T.POOR_TEST
The developer or tester performs insufficient tests to
demonstrate that all TOE security functions operate correctly
(including in a fielded TOE) may occur, resulting in incorrect
TOE behavior being undiscovered leading to flaws that may
be exploited by a mischievous user or program.
T.RESIDUAL_DATA A user or process may gain unauthorized access to data

through reallocation of TOE resources from one user or
process to another.
T.TSF_COMPROMISE A user or process may cause, through an unsophisticated
attack, TSF data, or executable code to be inappropriately
accessed (viewed, modified, or deleted).
T.UNATTENDED_ SESSION A user may gain unauthorized access to an unattended

session.
T.UNAUTHORIZED_ ACCESS A user may gain access to services (either on the TOE or by
sending data through the TOE) for which they are not
authorized according to the TOE security policy.
Page 13 of 85
T.UNAUTH_ADMIN_ACCESS An unauthorized user or process may gain access to an
administrative account.
3.3 Organizational Security Policies

An organizational security policy is a set of rules, practices, and procedures imposed by an
organization to address its security needs. Table 3-3 Organizational Security Policies identifies the
organizational security policies applicable to the TOE. The policies are identical to those of
WLANAS PP.
Table 3-3 Organizational Security Policies
Policy Name Policy Definition

P.ACCESS_BANNER The TOE shall display an initial banner for administrator logins
describing restrictions of use, legal agreements, or any other
appropriate information to which users consent by accessing
the system.
P.ACCOUNTABILITY The authorized users of the TOE shall be held accountable for
their actions within the TOE.
P.CRYPTOGRAPHIC The TOE shall provide cryptographic functions for its own use,
including encryption/decryption operations.
P.CRYPTOGRAPHY_VALIDATED Only NIST FIPS validated cryptography (methods and
implementations) are acceptable for key management (i.e.;
generation, access, distribution, destruction, handling, and
storage of keys) and cryptographic services (i.e.; encryption,
decryption, signature, hashing, key exchange, and random
number generation services).
P.ENCRYPTED_CHANNEL The TOE shall provide the capability to encrypt/decrypt

wireless network traffic between the TOE and those wireless
clients that are authorized to join the network.
P.NO_AD_HOC_NETWORKS In accordance with the DOD Wireless Policy, there will be no
ad hoc 802.11 or 802.15 networks allowed.
Page 14 of 85
4 Security Objectives
4.1 Security Objectives for the TOE

Table 4-1 Security Objectives for TOE identifies the security objectives of the TOE. These security
objectives reflect the stated intent to counter identified threats and/or comply with any
organizational security policies identified. The table also shows the corresponding threats and
policies that are addressed by the objectives. An explanation of the relationship between the
objectives and the threats/policies is provided in the rationale section of this document. The
Security Objectives for the TOE are identical to those of WLANAS PP.
Table 4-1 Security Objectives for TOE
Name TOE Security Objective

O.AUDIT_GENERATION The TOE will provide the capability to detect and create
records of security-relevant events associated with users.
O.CORRECT_TSF_OPERATION The TOE will provide the capability to verify the correct
operation of the TSF.
O.CRYPTOGRAPHY The TOE shall provide cryptographic functions to maintain
the confidentiality and allow for detection of modification of
user data that is transmitted between physically separated
portions of the TOE, or outside of the TOE.
O.CRYPTOGRAPHY_VALIDATED The TOE will use NIST FIPS 140-1/2 validated crypto
modules for cryptographic services implementing NIST-
approved security functions and random number generation
services used by cryptographic functions.
O.DISPLAY_BANNER The TOE will display an advisory warning prior to

establishing an administrator session regarding use of the
TOE prior to permitting the use of any TOE services that
requires authentication.
O.MANAGE The TOE will provide functions and facilities necessary to

support the administrators in their management of the
security of the TOE, and restrict these functions and facilities
from unauthorized use.
O.MEDIATE The TOE must mediate the flow of information to and from
wireless clients communicating via the TOE in accordance
with its security policy.
Page 15 of 85
O.RESIDUAL_ INFORMATION The TOE will ensure that any information contained in a
protected resource within its Scope of Control is not released
when the resource is reallocated.
O.SELF_PROTECTION The TSF will maintain a domain for its own execution that
protects itself and its resources from external interference,
tampering, or unauthorized disclosure through its own
interfaces.
O.TIME_STAMPS The TOE shall obtain reliable time stamps.

O.TOE_ACCESS The TOE will provide mechanisms that control a user’s
logical access to the TOE.
O.ADMIN_GUIDANCE The TOE will provide administrators with the necessary
information for secure management.
O.CONFIGURATION_ The configuration of the TOE is fully identified in a manner
IDENTIFICATION that will allow implementation errors to be identified,
corrected with the TOE being redistributed promptly.
O.DOCUMENTED_ DESIGN The design of the TOE is adequately and accurately

documented.
O.PARTIAL_ The TOE will undergo some security functional testing that
FUNCTIONAL_TESTING demonstrates the TSF satisfies some of its security
functional requirements.
O.VULNERABILITY_ ANALYSIS The TOE will undergo some vulnerability analysis
demonstrate the design and implementation of the TOE does
not contain any obvious flaws.
4.2 Security Objectives for the Environment
The assumptions identified in Section 3.1 are incorporated as security objectives for the
environment and listed below. They levy additional requirements on the environment, which are
largely satisfied through procedural or administrative measures. Table 4-2 Security Objectives for
the IT and Non IT Environment identifies the security objectives for the TOE IT and Non
environment. The objectives are identical to those of WLANAS PP.
Table 4-2 Security Objectives for the IT and Non IT Environment
Name Security Objective
Page 16 of 85
OE.AUDIT_PROTECTION The IT Environment will provide the capability to protect audit
information and the authentication credentials.
OE.AUDIT_REVIEW The IT Environment will provide the capability to selectively view

audit information.
OE.MANAGE The TOE IT environment will augment the TOE functions and
facilities necessary to support the administrators in their
management of the security of the TOE, and restrict these
functions and facilities from unauthorized use.
OE.NO_EVIL Sites using the TOE shall ensure that administrators are non-
hostile, appropriately trained and follow all administrator
guidance.
There are no general-purpose computing or storage repository
OE.NO_GENERAL_PURPOSE
capabilities (e.g., compilers, editors, or user applications)
available on the TOE.
OE.PHYSICAL The environment provides physical security commensurate with
the value of the TOE and the data it contains.
OE.PROTECT_MGMT_COMMS The environment shall protect the transport of audit records to

the audit server, remote network management, and
authentication server communications with the TOE and time
service in a manner that is commensurate with the risks posed
to the network.
OE.RESIDUAL_INFORMATION The TOE IT environment will ensure that any information

contained in a protected resource within its Scope of Control is
not released when the resource is reallocated.
OE.SELF_PROTECTION The environment will maintain a domain for its own execution
that protects itself and its resources from external interference,
tampering, or unauthorized disclosure through its own interfaces.
OE.TIME_STAMPS The TOE IT environment shall provide reliable time stamps and
the capability for the administrator to set the time used for these
time stamps.
OE.TOE_ACCESS The environment will provide mechanisms that support the TOE
in providing a user’s logical access to the TOE.
OE.TOE_NO_BYPASS Wireless clients are configured so that information cannot flow

between a wireless client and any other wireless client or host
networked to the TOE without passing through the TOE.
Page 17 of 85
5 IT Security Requirements
This section provides functional and assurance requirements that must be satisfied by the TOE and
the IT environment.
5.1 Strength of Function Claims

The statement of the TOE security requirements must include a minimum strength level for the TOE
security functions realized by a probabilistic or permutational mechanism, except for cryptographic
functions. For this ST, the overall level will be SoF-basic.
In the event that a probabilistic mechanism, such as a password mechanism for user and/or
administrator authentication is used, then the expectation is that for each attempt to use the
authentication mechanism, the probability that a random attempt will succeed is less than one in a
million. FIA_UAU.1 includes the following probabilistic/permutational mechanisms for which specific
SOF metrics are appropriate: password-based authentication.
The strength of function claims in this ST match those of WLANAS PP.
5.2 TOE Security Functional Requirements

The TOE security functional requirements are listed in Table 5-1 Functional Components. The
requirement names ending with _EXP correspond to explicitly stated requirements. All other
requirements are drawn from CC Part 2.
Table 5-1 Functional Components
Component Component Name Dependencies

FAU_GEN.1(1) Audit data generation FPT_STM.1
FAU_GEN.2 User identity association FAU_GEN.1
FIA_UID.1
FAU_SEL.1 Selective audit FAU_GEN.1;
FMT_MTD.1(1)
FCS_BCM_EXP.1 Explicit: baseline cryptographic module None
FCS_CKM.1 Cryptographic key generation [FCS_CKM.2 or
FCS_COP.1]
FCS_CKM.4
FMT_MSA.2
FCS_CKM_EXP.2 Cryptographic key establishment [FTP_ITC.1 or
FCS_CKM.1]
FMT_MSA.2
Page 18 of 85
FCS_CKM.4 Cryptographic key destruction FTP_ITC.1 or
FCS_CKM.1]
FMT_MSA.2
FCS_COP_EXP.1 Explicit: random number generation [FTP_ITC.1or
FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FCS_COP_EXP.2 Explicit: cryptographic operation [FTP_ITC.1 or
FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FDP_PUD_EXP.1 Protection of user data None
FDP_RIP.1(1) Subset residual information protection None
FIA_AFL.1(1) Administrator authentication failure FIA_UAU.1
handling
FIA_ATD.1(1) Administrator attribute definition None
FIA_UAU.1 Timing of local authentication FIA_UID.1
FIA_UAU_EXP.5(1) Multiple authentication mechanisms None
FIA_UID.2 User identification before any action None
FIA_USB.1(1) User-subject binding FIA_ATD.1(1)
FIA_USB.1(2) User-subject binding FIA_ATD.1(1)
FMT_MOF.1(1) Management of security functions FMT_SMF.1(1)
behavior (cryptographic function)
FMT_SMR.1(1)
behavior (audit record generation)
FMT_SMR.1(1)
behavior (authentication)
FMT_SMR.1(1)
FMT_MSA.2 Secure security attributes ADV_SPM.1
[FDP_ACC.1 or
FDP_IFC.1]
FMT_MSA.1
FMT_SMR.1(1)
FMT_MTD.1(1) Management of audit data FMT_SMR.1(1)
FMT_SMF.1(2)
FMT_MTD.1(2) Management of authentication data FMT_SMR.1(1)
Page 19 of 85
(administrator) FMT_SMF.1(1)
FMT_SMF.1(1) Specification of management functions None
(cryptographic functions)
(TOE audit record generation)
(Cryptographic key data)
FMT_SMR.1(1) Security roles FIA_UID.1
FPT_RVM.1(1) Non-bypassability of the TOE Security None
Policy (TSP)
FPT_SEP.1(1) TSF domain separation None
FPT_STM_EXP.1 Reliable time stamps None
FPT_TST_EXP.1 TSF testing FCS_CKM.2, FCS_CKM.4,
FCS_COP_EXP.1,
FCS_COP_EXP.2
FPT_TST_EXP.2 TSF testing of cryptographic modules FCS_CKM.2, FCS_CKM.4,
FCS_COP_EXP.1,
FCS_COP_EXP.2
FTA_SSL.3 TSF-initiated termination None
FTA_TAB.1 Default TOE access banners None
FTP_ITC_EXP.1(1) Inter-TSF trusted channel None
FTP_TRP.1 Trusted path None
5.2.1 Security Audit
5.2.1.1 FAU_GEN.1(1) Audit data generation
FAU_GEN.1.1(1) The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the minimum level of audit; and
c) [none].
Page 20 of 85
Table 5-2 TOE Auditable Events
Requirement Auditable Events Additional Audit Record

Contents
FAU_GEN.1 None None
FAU_GEN.2 None None
FAU_SEL.1 All modifications to the audit configuration that The identity of the
occur while the audit collection functions are Administrator performing
operating the function
FCS_CKM.1 Manual load of a key The identity of the
Administrator performing
the function
FCS_CKM_EXP.2 Error(s) detected during cryptographic key transfer None
FCS_CKM.4 Destruction of a cryptographic key The identity of the

Administrator performing
the function
FCS_COP_EXP.1 None None
FCS_COP_EXP.2 None None
FDP_PUD.1_EXP Enabling or disabling TOE encryption of wireless The identity of the
traffic Administrator performing
the function.
FDP_RIP.1(1) None None
FIA_AFL.1(1) The reaching of the threshold for the unsuccessful None
authentication attempts and the actions (e.g.
disabling of a terminal) taken and the subsequent, if
appropriate, restoration to the normal state (e.g. re-
enabling of a terminal)
FIA_ATD.1(1) None None

FIA_UAU.1 Use of the authentication mechanism (success or User identity - the TOE
failure) SHALL NOT record invalid
passwords the audit log.
FIA_UAU_EXP.5(1) Failure to receive a response from the remote Identification of the
authentication server Authentication server that
did not reply
FIA_UID.2 None None
FIA_USB.1(1) Unsuccessful binding of user security attributes to a None
FIA_USB.1(2) subject
FMT_MOF.1(1) Changing the TOE encryption algorithm including Encryption algorithm
the selection not to encrypt communications selected (or none)
FMT_MOF.1(2) Start or Stop of audit record generation None
Page 21 of 85
FMT_MOF.1(3) Changes to the TOE remote authentication settings; The identity of the
Changes to the threshold of failed authentication Administrator performing
attempts; the function.
Changes to the session lock timeframe
FMT_MSA.2 All offered and rejected values for security None

attributes
FMT_MTD.1(1) Changes to the set of rules used to pre-select audit None
events.
FMT_MTD.1(2) Changing the TOE authentication credentials None – the TOE SHALL
NOT record authentication
credentials in the audit log.
FMT_SMR.1(1) Modifications to the group of users that are part of a None
role
FPT_STM_EXP.1 Changes to the time None
FPT_TST_EXP.1 Execution of the self test Success or Failure of test
FPT_TST_EXP.2 Execution of the self test Success or Failure of test
FTA_SSL.3 TSF Initiated Termination Termination of an interactive
session by the session
locking mechanism.
FTP_ITC_EXP.1(1) Initiation/Closure of a trusted channel; Identification of the remote
entitywith which the channel
was attempted/created;
Success of failure of the
event
FTP_TRP.1 Initiation of a trusted path Identification of the remote
entity with which the path
was attempted/created;
event
FAU_GEN.1.2(1) 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 (if applicable), 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 in FAU_GEN.1.1(1)].
Application Note: Event type is defined as the BSD syslog severity level indicator, in the Terminology section
of the WLANAS PP.
Page 22 of 85
5.2.1.2 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.
5.2.1.3 FAU_SEL.1 Selective audit
FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited
events based on the following attributes:
a) user identity, event type
b) [device interface, wireless client identity].
Application Note: Event type is defined as the BSD syslog severity level indicator, in the Terminology section
of the WLANAS PP.
Application Note: The device interface is the physical interface upon which user (or administrative) data is
received/sent (e.g. WLAN interface, wired LAN interface, serial port, administrative LAN interface, etc.).
5.2.1.4 FCS_BCM_EXP.1 Explicit: baseline cryptographic module
FCS_BCM_EXP.1.1 All cryptographic modules shall comply with FIPS 140-1/2 when performing
FIPS approved cryptographic functions in FIPS approved cryptographic modes of operation.
FCS_BCM_EXP.1.2 The cryptographic module implemented shall have a minimum overall rating
of Level 1.
FCS_BCM_EXP.1.3 The FIPS validation testing of the TOE cryptographic module(s) shall be in
conformance with FIPS 140-1, 140-2, or the most recently approved FIPS 140 standard for which
NIST is accepting validation reports from Cryptographic Modules Testing laboratories.
5.2.1.5 FCS_CKM.1 Cryptographic key generation
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [ANSI X9.31 PRNG] and specified cryptographic key sizes
[112-bit Triple DES, 168-bit Triple DES, 128-bit AES, 196-bit AES, 256-bit AES, 1024-bit RSA] that
meet the following: [FIPS 140-2 standard].
5.2.1.6 FCS_CKM_EXP.2 Explicit: cryptographic key establishment
FCS_CKM_EXP.2.1 The TSF shall provide the following cryptographic key establishment
technique: Cryptographic Key Establishment using Manual Loading. The cryptomodule shall be able
to accept as input and be able to output keys in the following circumstances [upon issuance of the
key input/output command by the administrator] in accordance with a specified manual
cryptographic key distribution method using FIPS-approved Key Management techniques that
meets the FIPS 140-1/2 Key Management Security Levels 1, Key Entry and Output.
Page 23 of 85
5.2.1.7 FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified key
destruction method [cryptographic key zeroization method] that meets the following:[
a) The Key Zeroization Requirements in FIPS PUB 140-1/2 Key Management Security Levels 1;
b) Zeroization of all private cryptographic keys, plaintext cryptographic keys, key data, and all other
critical cryptographic security parameters shall be immediate and complete; and
c) The zeroization shall be executed by overwriting the key/critical cryptographic security parameter
storage area three or more times with an alternating pattern.
d) The TSF shall overwrite each intermediate storage area for private cryptographic keys, plaintext
cryptographic keys, and all other critical security parameters three or more times with an alternating
pattern upon the transfer of the key/CSPs to another location.]
Application Note: Item (d) applies to locations that are used when the keys/parameters are copied during
processing, and not to the locations that are used for storage of the keys, which are specified in items (b) and
(c). The temporary locations could include memory registers, physical memory locations, and even page files
and memory dumps. Configuring the key data may include: setting key lifetimes, setting key length, etc.
5.2.1.8 FCS_COP_EXP.1 Explicit: random number generation
FCS_COP_EXP.1.1 The TSF shall perform all Random Number Generation used by the
cryptographic functionality of the TSF using a FIPS-approved Random Number Generator
implemented in a FIPS-approved cryptomodule running in a FIPS-approved mode.
Application Note: Whenever a referenced standard calls for a random number generation capability, this
requirement specifies the subset of random number generators (those that are FIPS-validated) that are
acceptable. Although the RNG is required to be implemented in a FIPS cryptomodule, it is not required that it
be implemented in the cryptomodule that is performing the cryptographic operations that satisfy
FCS_COP_EXP.2. Also note that this requirement is not calling for the RNG functionality to be made
generally available (e.g., to untrusted users via an API).
5.2.1.9 FCS_COP_EXP.2(1) Explicit: cryptographic operation
FCS_COP_EXP.2.1(1) A cryptomodule shall perform encryption and decryption using the FIPS-
140-1/2 Approved AES algorithm and operating in [CCM mode, CBC mode] and supporting FIPS
approved key sizes of [128 bits, 196 bits, 256 bits].
5.2.1.10 FCS_COP_EXP.2(2) Explicit: cryptographic operation
FCS_COP_EXP.2.1(2) A cryptomodule shall perform encryption and decryption using the FIPS-
140-1/2 Approved Triple DES algorithm and operating in [CBC mode] and supporting FIPS
approved key sizes of [112 bits, 168 bits].
Page 24 of 85
5.2.1.11 FDP_PUD_EXP.1 Protection of user data
FDP_PUD_EXP.1.1 When the administrator has enabled encryption, the TSF shall:
encrypt authenticated user data transmitted to a wireless client from the radio interface of the
wireless access system using the cryptographic algorithm(s) specified in FCS_COP_EXP.2
utilizing 802.11i wireless security protocol;
decrypt authenticated user data received from a wireless client by the radio interface of the wireless
access system using the cryptographic algorithm(s) specified in FCS_COP_EXP.2 utilizing 802.11i
wireless security protocol.
Application Note: This requirement allows the TOE administrator to require that all user data transmitted on
the WLAN be encrypted using the cryptographic algorithms specified by FCS_COP.
5.2.1.12 FDP_RIP.1(1) Subset residual information protection
FDP_RIP.1.1(1) The TSF shall ensure that any previous information content of a resource is made
unavailable upon the deallocation of the resource from the following objects: [network packet
objects].
Application Note: This requirement ensures that the TOE does not allow data from a previously transmitted
packet to be inserted into unused areas or padding in the current packet.
5.2.1.13 FIA_AFL.1(1) Administrator authentication failure handling
FIA_AFL.1.1(1) The TSF shall detect when an administrator configurable positive integer within the
range of [1 to 1024] of unsuccessful authentication attempts occur related to [remote administrators
logging on to the WLAN access system].
FIA_AFL.1.2(1) When the defined number of unsuccessful authentication attempts has been met or
surpassed, the TSF shall [prevent remote login by administrators until an action is taken by a local
Administrator].
Application Note: This requirement applies to remote administrator login and does not apply to the local
login of the TOE, since it does not make sense to lock a local administrator’s account in this fashion. For the
purpose of the WLANAS PP, remote administrator refers to administrators that do not have either Serial
cable or local console access to the TOE.
Application Note: This requirement does NOT require that the TOE allow remote administration. However, if
the TOE does allow administrators to login to the TOE remotely (e.g. from the wired interface or a
management network) then it must provide a mechanism to prevent brute force attacks on the administrative
account.
5.2.1.14 FIA_ATD.1(1) Administrator attribute definition
FIA_ATD.1.1(1) The TSF shall maintain the following minimum list of security attributes belonging
to individual administrators: [password, [no additional attributes]].
Page 25 of 85
5.2.1.15 FIA_UAU.1 Timing of local authentication
FIA_UAU.1.1 The TSF shall allow [identification as provided in FIA_UID.2] on behalf of the user
users to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any
other TSF-mediated actions on behalf of that user.
5.2.1.16 FIA_UAU_EXP.5(1) Explicit: multiple authentication mechanisms
FIA_UAU_EXP.5.1(1) The TSF shall provide local password-based authentication of

administrators, and a remote authentication mechanism to perform user authentication.
FIA_UAU_EXP.5.2(1) The TSF shall, at the option of the administrator, invoke the remote
password-based authentication mechanism for administrators and the remote EAP-TLS, EAP-
TTLS, or PEAP-based authentication mechanism for wireless LAN users.
Application Note: This explicit requirement is needed for local administrators because there is disagreement
over whether existing CC requirements specifically require the TSF provide authentication. That the TOE
provide authentication is implied by other FIA_UAU requirements, and generally assumed to be a
requirement when other FIA_UAU requirements are included in a TOE. In order to remove any potential
confusion about this ST, an explicit requirement for authentication has been included. This ST mandates that
the TOE provide the client to facilitate remote authentication via an authentication server. The IT
environment will provide the authentication server, and it is important to specify that the TSF must provide
the means for local administrator authentication in case the TOE cannot communicate with the authentication
server.
Since FIA_UAU.5.1(1) and 5.2(1) require that the TSF provide authentication mechanisms, this explicit
requirement is needed with respect to the remote users to specify that the TSF invoke a remote authentication
mechanism rather than provide it.
5.2.1.17 FIA_UID.2 User identification before any action
FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSF-
mediated actions on behalf of that user.
Application Note: This requirement does not refer to management and control packets that must be allowed to
pass between the WLAN client and the access system before authentication. It is assumed that this information
is not user specific and therefore not covered by this requirement.
Application Note: It is also important to note that the identification credential presented to the authentication
server (e.g. a user name) will be related to but not necessarily the same as the identification credential (e.g.
MAC address of a remote system) that is used to enforce FDP_PUD_EXP.
5.2.1.18 FIA_USB.1(1) User-subject binding.
FIA_USB.1.1(1) The TSF shall associate the following wireless user security attributes with
subjects acting on the behalf of that user: [username].
Page 26 of 85
FIA_USB.1.2(1) The TSF shall enforce the following rules on the initial association of user security
attributes with subjects acting on the behalf of users: [upon successful identification and
authentication the username shall be that of the user that has authenticated successfully].
FIA_USB.1.3(1) The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users: [no changes shall be allowed].
5.2.1.19 FIA_USB.1(2) User-subject binding.
FIA_USB.1.1(2) The TSF shall associate the following administrator user security attributes with
subjects acting on the behalf of that user: [username].
FIA_USB.1.2(2) The TSF shall enforce the following rules on the initial association of user security
attributes with subjects acting on the behalf of users: [upon successful identification and
authentication the username shall be that of the user that has authenticated successfully].
FIA_USB.1.3(2) The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users: [no changes shall be allowed].
5.2.1.20 FMT_MOF.1(1) Management of cryptographic security functions behavior
FMT_MOF.1.1(1) The TSF shall restrict the ability to modify the behavior of the cryptographic
functions [
• Crypto: load a key
• Crypto: delete/zeroize a key
• Crypto: set a key lifetime
• Crypto: set the cryptographic algorithm
• Crypto: set the TOE to encrypt or not to encrypt wireless transmissions
• Crypto: execute self tests of TOE hardware and the cryptographic functions]
to [administrators].
5.2.1.21 FMT_MOF.1(2) Management of audit security functions behavior
FMT_MOF.1.1(2) The TSF shall restrict the ability to enable, disable, and modify the behavior of the
functions [
• Audit: pre-selection of the events which trigger an audit record,
• Audit: start and stop of the audit function]
Page 27 of 85
5.2.1.22 FMT_MOF.1(3) Management of authentication security functions behavior
FMT_MOF.1.1(3) The TSF shall restrict the ability to modify the behavior of the Authentication
functions [
• Auth: allow or disallow the use of an authentication server
• Auth: set the number of authentication failures that must occur before the TOE takes action to
disallow future logins
• Auth: set the length of time a session may remain inactive before it is terminated]
5.2.1.23 FMT_MSA.2 Secure security attributes
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes.
5.2.1.24 FMT_MTD.1(1) Management of Audit pre-selection data
FMT_MTD.1.1(1) The TSF shall restrict the ability to query, modify, clear, [create] the [set of rules
used to pre-select audit events] to [the administrator].
5.2.1.25 FMT_MTD.1(2) Management of authentication data (administrator)
FMT_MTD.1.1(2) The TSF shall restrict the ability to query, modify, delete, clear, [create] the
[authentication credentials] to [administrators].
5.2.1.26 FMT_SMF.1(1) Specification of management functions (cryptographic function)
FMT_SMF.1.1(1) The TSF shall be capable of performing the following security management
functions: [configure administrator authentication, query and set the encryption/decryption of
network packets (via FCS_COP_EXP.2) in conformance with the administrators configuration of the
TOE].
Application Note: This requirement ensures that those responsible for TOE administration are able to select
an encryption algorithm identified in FCS_COP_EXP.2 or no encryption for encrypting/decrypting data
transmitted by the WLAN device.
5.2.1.27 FMT_SMF.1(2) Specification of management functions (TOE audit record generation)
functions: [query, enable or disable Security Audit].
Application Note: This requirement ensures that those responsible for TOE administration are able to start or
stop the TOE generation of audit records
Page 28 of 85
5.2.1.28 FMT_SMF.1(3) Specification of management functions (cryptographic key data)
functions: [query, set, modify, and delete the cryptographic keys and key data in support of
FDP_PUD_EXP and enable/disable verification of cryptographic key testing].
Application Note: The intent of this requirement is to provide the ability to configure the TOE’s cryptographic
key(s). Configuring the key data may include: setting key lifetimes, setting key length, etc.
5.2.1.29 FMT_SMR.1(1) Security roles
FMT_SMR.1.1(1) The TSF shall maintain the roles [administrator, wireless user].
FMT_SMR.1.2(1) The TSF shall be able to associate users with roles.
Application Note: The only user allowed direct access to the TOE is the administrator. Wireless users can
pass data through the TOE but do not have direct access. A role of wireless user is included in the TOE, but
the scope of that role should be defined only to the extent necessary to support the activities of wireless users
passing data through the TOE.
This ST also assumes that the TOE will contain a local authentication mechanism and the capability to use a
remote authentication server. Although users are sometimes referred to as local or remote, these references
do not imply a role.
5.2.1.30 FPT_RVM.1(1) Non-bypassability of the TOE Security Policy (TSP)
FPT_RVM.1.1(1) The TSF shall ensure that TSP enforcement functions are invoked and succeed
before each function within the TSC is allowed to proceed.
5.2.1.31 FPT_SEP.1(1) TSF domain separation
FPT_SEP.1.1(1) The TSF shall maintain a security domain for its own execution that protects it
from interference and tampering by untrusted subjects.
FPT_SEP.1.2(1) The TSF shall enforce separation between the security domains of subjects in the
TSC.
5.2.1.32 FPT_STM_EXP.1 Reliable time stamps
FPT_STM_EXP.1.1 The TSF shall be able to provide reliable time stamps, synchronized via an
external time source, for its own use.
Application Note: The TOE must be capable of obtaining a time stamp via an NTP server.
5.2.1.33 FPT_TST_EXP.1 TSF testing
FPT_TST_EXP.1.1 The TSF shall run a suite of self-tests during initial start-up and upon request, to
demonstrate the correct operation of the hardware portions of the TSF.
Page 29 of 85
FPT_TST_EXP.1.2 The TSF shall provide the capability to use a TSF-provided cryptographic
function to verify the integrity of all TSF data except the following: audit data, [temporary files, page
files, configuration files, core dumps, data stored in volatile memory].
FPT_TST_EXP.1.3 The TSF shall provide the capability to use a TSF-provided cryptographic
function to verify the integrity of stored TSF executable code.
5.2.1.34 FPT_TST_EXP.2 TSF testing of cryptographic modules
FPT_TST_EXP.2.1 The TSF shall run the suite of self-tests provided by the FIPS 140-1/2
cryptomodule during initial start-up (power on) and upon request, to demonstrate the correct
operation of the cryptographic components of the TSF.
FPT_TST_EXP.2.2 The TSF shall be able to run the suite of self-tests provided by the FIPS 140-
1/2 cryptomodule immediately after the generation of a key.
Application Note: In 2.2 it is required that there be specific functionality IF the TOE generates cryptographic
keys. This requirement does not require the TOE to generate keys.
5.2.1.35 FTA_SSL.3 TSF-initiated termination
FTA_SSL.3.1 The TSF shall terminate an a local interactive or wireless session after a an
[administrator configurable time interval of user inactivity].
Application Note: This requirement applies to both local administrative sessions and wireless users that pass
data through the TOE.
5.2.1.36 FTA_TAB.1 Default TOE access banners
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorized use of the TOE.
5.2.1.37 FTP_ITC_EXP.1(1) Inter-TSF trusted channel
FTP_ITC_EXP.1.1(1) The TOE shall provide an IPSec/IKE encrypted communication channel

between itself and entities in the TOE IT Environment that is logically distinct from other
communication channels and provides assured identification of its end points and protection of the
channel data from modification or disclosure.
FTP_ITC_EXP.1.2(1) The TSF shall permit the TSF, or the IT Environment entities to initiate
communication via the trusted channel.
FTP_ITC_EXP.1.3(1) The TSF shall initiate communication via the trusted channel for [all
authentication functions, remote logging, time, none].
Page 30 of 85
5.2.1.38 FTP_TRP.1 Trusted path
FTP_TRP.1.1 The TSF shall provide a communication path between itself and wireless users that
is logically distinct from other communication paths and provides assured identification of its end
points and protection of the communicated data from modification, replay or disclosure.
FTP_TRP.1.2 The TSF shall permit wireless client devices to initiate communication via the
trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for wireless user authentication,
[none].
Application Note: This requirement ensures that the initial exchange of authentication information between
the wireless client and the access system is protected.
5.3 Security Requirements for the IT Environment.
This ST includes functional requirements for the IT Environment. The IT environment includes an
authentication server, a time server and an audit server.
In support of the audit server, the environment shall provide the capability to protect audit
information and authentication credentials. The environment shall also provide the capability to
selectively view the audit data.
In support of the authentication server, the environment shall provide facilities to manage
authentication information and limit brute force password attacks.
It is expected that the communications between these entities and the TOE will be protected. In
addition, the TOE IT environment is responsible for protecting itself and ensuring that its security
mechanisms cannot be bypassed.
The IT Environment security functional requirements are listed in Table 5-3 Functional
Components.
Table 5-3 Functional Components
Component Component Name Dependencies

FAU_GEN.1(2) Audit data generation FPT_STM.1
FAU_SAR.1 Audit review FAU_GEN.1
FAU_SAR.2 Restricted audit review FAU_SAR.1
FAU_SAR.3 Selectable audit review FAU_SAR.1
FAU_STG.1 Protected audit trail storage FAU_GEN.1
FAU_STG.3 Action in case of possible audit data loss FAU_STG.1
Page 31 of 85
FDP_RIP.1(2) Subset residual information protection None
FIA_AFL.1(2) Remote user authentication failure FIA_UAU.1

handling
FIA_ATD.1(2) User attribute definition None
FIA_UAU_EXP.5(2) Remote authentication mechanisms FIA_UID.1
FIA_UID.1 Timing of identification None

FMT_MOF.1(4) Management of security functions FMT_SMF.1(1)(2)(3)
Behavior FMT_SMR.1
FMT_MTD.1(3) Management of identification data FMT_SMF.1(4)

(user) FMT_SMR.1(2)
FMT_MTD.1(4) Management of authentication data FMT_SMF.1(4)
(user) FMT_SMR.1(2)
FMT_MTD.1(5) Management of time data FMT_SMF.1(5)
FMT_SMR.1(2)
FMT_SMR.1(2) Security roles FIA_UID.1
(user identification and authentication)
(time stamps)
FTP_ITC_EXP.1(2) Inter-TSF trusted channel None
FPT_RVM.1(2) Non-bypassability of the TOE Security None
Policy (TSP)
FPT_SEP.1(2) TSF domain separation None
FPT_STM.1 Reliable time stamps None
5.3.1.1 FAU_GEN.1(2) Audit data generation
FAU_GEN.1.1(2) The TOE IT Environment shall be able to generate an audit record of the
following auditable events:
a. Start-up and shutdown of the audit functions;
b. All auditable events for the [minimum] level of audit; and
c. [none].
Table 5-4 TOE IT Environment Auditable Events
Page 32 of 85
Requirement Auditable Events Additional Audit

Record Contents
FAU_GEN.1(2) None None
FAU_SAR.1 None None
FAU_SAR.2 Unsuccessful attempt to read the audit records The identity of the user
attempting to perform the
function
FAU_SAR.3 None None
FAU_STG.1 None None
FAU_STG.3 Any actions taken when audit trail limits are exceeded None
FDP_RIP.1(2) None None

FIA_AFL.1(2) The reaching of the threshold for the unsuccessful None
authentication attempts and the actions (e.g. disabling
of a terminal) taken and the subsequent, if appropriate,
restoration to the normal state (e.g. re-enabling of a
terminal
FIA_ATD.1(2) None None

FIA_UAU_EXP.5(2) Use of the authentication mechanism (success or User identity - the TOE
failure) SHALL NOT record
invalid passwords the
audit log.
FIA_UID.1 None None
FMT_MOF.1(4) Changes to audit server settings None
Changes to authentication server settings
Changes to time server settings
FMT_MTD.1(3) Changing the authentication credentials None – the IT

FMT_MTD.1(4) environment SHALL
NOT record
authentication credentials
in the audit log.
FMT_MTD.1(5) Changes to the time data None
FMT_SMR.1(2) None None
FTP_ITC_EXP.1(2) Initiation/Closure of a trusted channel; Identification of the
remote entity with which
the channel was
attempted/created;
event
FPT_RVM.1(2) None None
FPT_SEP.1(2) None None
FPT_STM.1 Setting time/date Identity of the
administrator that
Page 33 of 85
performed the action
FAU_GEN.1.2(2) The TOE IT environment shall record within each audit record at least the
following information:
a) Date and time of the event, type of event, subject identity (if applicable), 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 in FAU_GEN.1.1(2)].
Application Note: Event type is defined as the BSD syslog severity level indicator in the Terminology section
of the WLANAS PP.
5.3.1.2 FAU_SAR.1 Audit review
FAU_SAR.1.1 The TOE IT environment TSF shall provide only the [Administrator] with the
capability to read [all audit data] from the audit records.
FAU_SAR.1.2 The TOE IT environment TSF shall provide the audit records in a manner suitable
for the administrator to interpret the information.
Application Note: This requirement ensures that the TOE IT environment provides the administrator with
functionality necessary for the administrator to review the audit records generated by the TOE.
5.3.1.3 FAU_SAR.2 Restricted audit review
FAU_SAR.2.1 The TOE IT environment TSF shall prohibit all users read access to the audit
records, except those users that have been granted explicit read-access.
Application Note: This requirement ensures that access to audit records generated by the TOE is limited to
those authorized to view the information.
5.3.1.4 FAU_SAR.3 Selectable audit review
FAU_SAR.3.1 The TOE IT environment TSF shall provide the ability to perform searches of audit
data based on [event type, date, time and/or [no additional criteria]].
5.3.1.5 FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TOE IT environment TSF shall protect the stored audit records from
unauthorized deletion.
FAU_STG.1.2 The TOE IT environment TSF shall be able to prevent unauthorized modifications to
the stored audit records in the audit trail.
Page 34 of 85
5.3.1.6 FAU_STG.3 Action in case of possible audit data loss
FAU_STG.3.1 The TOE IT environment TSF shall [immediately alert the administrators by
displaying a message at the local console, none] if the audit trail exceeds [an administrator-settable
percentage of storage capacity].
5.3.1.7 FDP_RIP.1(2) Subset residual information protection
FDP_RIP.1.1(2) The TOE IT Environment TSF shall ensure that any previous information content
of a resource is made unavailable upon the allocation of the resource to the following objects:
[network packet objects]
Application Note: This requirement ensures that the TOE environment does not allow data from a previously
transmitted packet to be inserted into unused areas or padding in the current packet. Since operations on
requirement for the IT environment must be completed, the selection “allocation of resources to” has been
made because it is encompassing of the two options (e.g. a system that make the information contents of
resource unavailable when the resource is freed can also claim to meet the requirement that the content of the
resource be freed prior to reallocation).
5.3.1.8 FIA_AFL.1(2) Remote user authentication failure handling
FIA_AFL.1.1(2) The TOE IT Environment TSF shall detect when an administrator configurable
positive integer within [1 to 1024] of unsuccessful authentication attempts occur related to [remote
users logging on to the WLAN access system].
FIA_AFL.1.2(2) When the defined number of unsuccessful authentication attempts has been met or
surpassed, the TSF shall [prevent the remote user from authenticating until action is taken by an
administrator].
Application Note: This requirement ensures that the TOE IT Environment has the capability to detect multiple
authentication attempts and take action to disable subsequent authentication attempts.
5.3.1.9 FIA_ATD.1(2) User attribute definition
FIA_ATD.1.1(2) The TOE IT Environment TSF shall maintain the following minimum list of
security attributes belonging to individual remotely authenticated users: [password for users
authenticating using EAP-TTLS and PEAP authentication protocols].
5.3.1.10 FIA_UAU_EXP.5(2) Remote authentication mechanisms
FIA_UAU_EXP.5.1(2) The TOE IT Environment TSF shall provide [a remote authentication

mechanism] to provide TOE remote user authentication.
FIA_UAU_EXP.5.2(2) The TOE IT Environment TSF shall authenticate any user’s claimed identity
according to the [EAP-TLS, EAP-TTLS, or PEAP authentication protocols].
Page 35 of 85
5.3.1.11 FIA_UID.1 Timing of identification
FIA_UID.1.1 The TOE IT environment TSF shall allow [no actions] on behalf of the TOE remote
user to be performed before the user is identified.
FIA_UID.1.2 The TOE IT environment TSF shall require each TOE remote user to identify itself
before allowing any other IT environment or TSF-mediated actions on behalf of that TOE remote
user.
Application Note: This requirement does not refer to management and control packets that must be allowed to
pass between the wlan client and the access system before authentication. It is assumed that this information
is not user specific and therefore not covered by this requirement.
5.3.1.12 FMT_SMF.1(4) Specification of management functions (user identification and

authentication)
FMT_SMF.1.1(1) The TOE IT environment TSF shall be capable of performing the following
security management functions: [configure user identification and authentication].
5.3.1.13 FMT_SMF.1(5) Specification of management functions (time stamps)
FMT_SMF.1.1(2) The TOE IT environment TSF shall be capable of performing the following
security management functions: [configure time stamps].
5.3.1.14 FMT_MOF.1(4) Management of security functions behavior
FMT_MOF.1.1(4) The TOE IT environment TSF shall restrict the ability to determine the behavior
of the functions: [
• Audit,
• Remote Authentication
• Time service]
to [the administrator].
Application Note: The TOE IT environment must be managed in conjunction with the TOE.
5.3.1.15 FMT_MTD.1(3) Management of identification data (user)
FMT_MTD.1.1(3) The TOE IT environment TSF shall restrict the ability to query, modify, delete,
clear, [create] the [user identification credentials] to [administrators].
5.3.1.16 FMT_MTD.1(4) Management of authentication data (user)
FMT_MTD.1.1(4) The TOE IT environment TSF shall restrict the ability to modify the [user
authentication credentials] to [administrators].
Page 36 of 85
5.3.1.17 FMT_MTD.1(5) Management of time data
FMT_MTD.1.1(5) The TOE IT environment shall restrict the ability to [set] the [time and date used
to form the time stamps in FPT_STM.1] to [the Security Administrator or authorized IT entity].
5.3.1.18 FMT_SMR.1(2) Security roles
FMT_SMR.1.1(2) The TOE IT environment TSF shall maintain the roles [administrator].
FMT_SMR.1.2(2) The TOE IT environment TSF shall be able to associate users with roles.
Application Note: The TOE IT environment must include an administrative role for its own management.
5.3.1.19 FTP_ITC_EXP.1(2) Inter-TSF trusted channel
FTP_ITC_EXP.1.1(2) The TOE IT environment TSF shall provide an IPSec/IKE encrypted

communication channel between itself and the TOE that is logically distinct from other
communication channels and provides assured identification of its end points and protection of the
channel data from modification or disclosure.
FTP_ITC_EXP.1.2(2) The TOE IT Environment TSF shall permit the TSF, or the TOE IT
Environment entities to initiate communication via the trusted channel.
FTP_ITC_EXP.1.3(2) The TOE IT environment TSF shall initiate communication via the trusted
channel for [all authentication functions, remote logging, time, none].
Application Note: For FTP_ITC_EXP.1.1(2) it is expected that the environment be able to provide and
encrypted channel between the environment and the TOE. This is to provide for communications between
itself and the TOE, as end points, to protect the communications between the TOE and the IT environment.
5.3.1.20 FPT_RVM.1(2) Non-bypassability of the IT Environment Security Policy (TSP)
FPT_RVM.1.1(2) The TOE IT Environment TSF shall ensure that IT environment TSP
enforcement functions are invoked and succeed before each function within the IT environmental
scope of control TSC is allowed to proceed.
5.3.1.21 FPT_SEP.1(2) TSF domain separation
FPT_SEP.1.1(2) The TOE IT Environment TSF shall maintain a security domain for its own
execution that protects it from interference and tampering by untrusted subjects.
FPT_SEP.1.2(2) The TOE IT Environment TSF shall enforce separation between the security
domains of subjects in the IT environmental scope of control.
5.3.1.22 FPT_STM.1 Reliable time stamps
FPT_STM.1.1 The TOE IT environment TSF shall be able to provide reliable time and date
stamps for the TOE and its own use.
Page 37 of 85
Application Note: The TOE IT environment must provide reliable time stamps (for example: an NTP server).
It is also acceptable for the TOE to satisfy this requirement by providing its own time stamp.
5.4 TOE Security Assurance Requirements

The Security Assurance Requirements for the TOE are the assurance components of Evaluation
Assurance Level 4 (EAL4) augmented with ALC_FLR.2 (Flaw Remediation). The components are
taken from Part 3 of the Common Criteria. None of the assurance components are refined. The
assurance components are listed in Table 5-5 Assurance Components below. The components
meet or exceed the requirements of WLANAS PP.
Table 5-5 Assurance Components
Assurance class Assurance components

ACM_AUT.1 Partial CM automation
Configuration management ACM_CAP.4 Generation support and acceptance procedures
ACM_SCP.2 Problem tracking CM coverage
ADO_DEL.2 Detection of modification
Delivery and operation
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.2 Fully defined external interfaces
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.1 Subset of the implementation of the TSF
Development
ADV_LLD.1 Descriptive low-level design
ADV_RCR.1 Informal correspondence demonstration
ADV_SPM.1 Informal TOE security policy model
AGD_ADM.1 Administrator guidance
Guidance documents
AGD_USR.1 User guidance
ALC_DVS.1 Identification of security measures
ALC_FLR.2 Flaw remediation
Life cycle support
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: high-level design
Tests
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
Vulnerability assessment AVA_MSU.2 Validation of analysis
Page 38 of 85
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.2 Independent vulnerability analysis
Page 39 of 85
6 TOE Summary Specification

This chapter describes the security functions and associated assurance measures.
6.1 TOE Security Functions

The following security functions are implemented by the TOE
a) Security Audit
b) Cryptographic Support
c) User Data Protection
d) Identification and Authentication
e) Security Management
f) Protection of the TSF
g) TOE Access
h) Trusted Path/Channels
6.1.1 Security Audit
The Security Audit function includes generation of audit events for startup/shutdown of audit
functions, modifications to the audit configuration, manual load of a key, cryptographic key transfer
errors, cryptographic key destruction, enabling/disabling wireless encryption, reaching of the
unsuccessful authentication attempts threshold and re-enabling the user, user authentication
attempts, authentication server failures, configuration of security functions, execution of self tests,
initiation/closure of a trusted channel, and initiation of a trusted path. The specific events are listed
as a part of FAU_GEN.1(1) definition. Audit events include at least date and time of the event, type
of event, subject identify (if applicable), and outcome (success or failure) of the event. For some
events additional information is included, as specified in FAU_GEN.1(1). For each identified user,
the username is included in the audit event record. The TOE provides an ability to include/exclude
events based on username, threshold syslog level, device interface and wireless client MAC
address.
The following syslog levels are supported:
Syslog level Description

LOG_EMERG An emergency condition. The system is unusable
LOG_ALERT This message warrants an immediate action
LOG_CRIT Critical Condition
LOG_ERR Error
LOG_WARNING Warning
LOG_NOTICE Normal but a significant condition
LOG_INFO Information only
LOG_DEBUG This message appears only during debug mode
Page 40 of 85
The audit events records are transmitted to the external audit server over a secure IPSec/IKE
connection.
Reliable time stamps are used for audit records.
6.1.2 Cryptographic Support
The TOE utilizes cryptographic functions for the purposes of wireless data protection using 802.11i
protocol, for SSH trusted path used for the TOE administration, as well as for IPSec/IKE trusted
channel established between the TOE and external authentication, audit and time servers.
The cryptographic module implemented by the TOE complies with FIPS 140-2 requirements at
Security Level 2. The module implements cryptographic algorithms as specified in FCS_CKM.1,
FCS_COP_EXP.2(1), and FCS_COP_EXP.2(2). A key zeroization function implemented by the
module zeroizes all cryptographic keys and critical security parameters by overwriting the storage
area three times with an alternating pattern. All intermediate storage areas for cryptographic keys
and critical security parameters are zeroized upon the transfer of the key or CSP to another
location. The module implements an administrator command to manually input/output cryptographic
keys, including the IPSec/IKE pre-shared keys and RADIUS authentication key.
The module employs ANSI X9.31 FIPS 140-2 approved random number generator for key
generation purposes.
6.1.3 User Data Protection
The TOE implements a capability to protect authenticated user data exchanged with a wireless
client using 802.11i wireless security protocol, which utilizes AES-CCM encryption with 128-bit
keys. The keys are dynamically established by the external authentication server during EAP-TLS,
EAP-TTLS or PEAP authentication phase, and then transferred from the authentication server to
the TOE over a protected IPSec/IKE channel.
The memory locations corresponding to 802.11i and IP network packets processed by the TOE are
zeroized when the packet is processed.
6.1.4 Identification and Authentication
The TOE keeps a local database of administrator usernames and passwords and utilizes password-
based authentication to authenticate administrators connecting remotely using SSH protocol, or
locally using a serial console connection. The TOE also provides a capability to authenticate
administrator against an external RADIUS authentication server, however only internal
administrator database is used in the evaluated configuration. When a pre-defined number of
unsuccessful authentication attempts for a remote administrator has been reached, the
administrator user is disabled until re-enabled using a local console connection.
The TOE authenticates wireless users utilizing an external RADIUS authentication server, which
implements EAP-TLS, EAP-TTLS and PEAP protocols. The trusted channel between the TOE and
Page 41 of 85
the external authentication server is protected using IPSec/IKE security protocol with pre-shared
keys. EAP-TLS uses a client certificate for user authentication, the username is embedded in the
certificate. EAP-TTLS and PEAP use a password for user authentication.
No services are provided by the TOE until the user is successfully identified and authenticated.
6.1.5 Security Management
The TOE provides remote management using SSH protocol, as well as local management utilizing
a serial console connection.
The management interfaces provide capabilities to add, view and remove IPSec/IKE and RADIUS
cryptographic keys and key lifetime, create/delete administrator users and set administrator
passwords, set maximum number of unsuccessful administrator authentication attempts, re-enable
administrators, set maximum session idle time for administrators and wireless users, enable/disable
wireless encryption, enable/disable the use of an authentication server, set IP addresses of remote
authentication, audit and time servers, execute self-tests, set cryptographic algorithms used by
IPSec/IKE, zeroize cryptographic keys and CSPs, start and stop audit functions, execute self-tests,
select events which trigger an audit record, enable/disable verification of cryptographic key testing,
as well as view the corresponding settings.
All management functions require assumption of the administrator role upon successful
authentication of the administrator.
6.1.6 Protection of the TSF
The TOE provides for non-bypassability of the TOE Security Policy, and TSF domain separation.
The TSP enforcement functions are invoked and succeed before security functions in the TSC are
allowed to proceed. Each wireless user is authenticated before access is provided, and for
authenticated wireless users, each wireless user network packet is authenticated as a part of
802.11i security protocol before the packet is processed by the TOE. Each administrator is
authenticated before management access is provided and each network message coming from an
authenticated administrator is authenticated as a part of the SSH protocol.
For each authenticated wireless user and remote administrator the TOE associates the user with a
session object. The session object is then used to enforce domain separation for authenticated
wireless users and administrators. All enforcement operations are performed within the physical
boundary of the TOE. Connection to the remote authentication server is protected using an
IPSec/IKE-based trusted channel, which authenticates each incoming and outgoing network packet.
The TOE maintains an IPSec/IKE trusted channel to a remote network time protocol server, which
provides time used in reliable time stamps.
The TOE implements a set of FIPS 140-2 self-tests, which are executed during initial start-up and
upon administrator request. The TOE provides an option to run self-tests immediately after a key is
generated.
The TOE implements a set of critical self-tests, which are executed during initial start-up and upon
administrator request. The tests include an integrity check for TSF data and executable code.
If the self-tests fail, the TOE security functionalities and data output are disabled.
Page 42 of 85
6.1.7 TOE Access
The TOE terminates a local serial console administrator or a wireless user session after a
configurable time interval of user inactivity is reached. A default banner regarding unauthorized
access is displayed before establishing a user session.
6.1.8 Trusted Path/Channels
The TOE maintains a trusted channel with audit, authentication, and network time protocol servers.
The channel is protected by IPSec/IKE protocol with pre-shared keys and can be initiated by the
TOE or the servers.
The TOE maintains a trusted path with wireless users during the wireless user authentication
phase. The trusted path is based on EAP-TLS, EAP-TTLS and PEAP protocols and can be
established by wireless client devices with the help of the external authentication server, which
performs authentication and cryptographic key derivation operations required by the EAP-TLS,
EAP-TTLS and PEAP protocols.
6.2 Assurance Measures
The assurance requirements for this TOE are for Evaluation Assurance Level EAL4. The following
items are provided as evaluation evidence to satisfy the EAL4 assurance requirements:
Table 6-1 Assurance Measures
Security Assurance Requirement Evaluation Evidence Documentation

ACM_AUT.1 Partial CM automation Motorola Wireless Switch Configuration Management
Plan and Procedures
ACM_CAP.4 Generation support and Motorola Wireless Switch Configuration Management
acceptance procedures Plan and Procedures
ACM_SCP.2 Problem tracking CM Motorola Wireless Switch Configuration Management
coverage Plan and Procedures
ADO_DEL.2 Detection of modification Motorola Wireless Switch Delivery and Operation
Plan and Procedures
ADO_IGS.1 Installation, generation, and Motorola Wireless Switch Installation Guide
start-up procedures
ADV_FSP.2 Fully defined external Motorola Wireless Switch Functional Specification
interfaces
ADV_HLD.2 Security enforcing high-level Motorola Wireless Switch High-Level Design
design Specification
Page 43 of 85
ADV_IMP.1 Subset of the implementation A subset of the source code and hardware diagrams
of the TSF used to generate the TOE
ADV_LLD.1 Descriptive low-level design Motorola Wireless Switch Low-Level Design
Specification
ADV_RCR.1 Informal correspondence Motorola Wireless Switch Informal Correspondence
demonstration Demonstration
ADV_SPM.1 Informal TOE security policy Motorola Wireless Switch Security Policy Model
model
AGD_ADM.1 Administrator guidance Motorola Wireless Switch CLI Reference Guide
Motorola Wireless Switch Installation Guide
AGD_USR.1 User guidance Motorola Wireless Switch CLI Reference Guide

ALC_DVS.1 Identification of security Motorola Wireless Switch Life Cycle Management
measures Plan and Procedures
ALC_FLR.2 Flaw Remediation Motorola Wireless Switch Life Cycle Management
Plan and Procedures
ALC_LCD.1 Developer defined life-cycle Motorola Wireless Switch Life Cycle Management
model Plan and Procedures
ALC_TAT.1 Well-defined development Motorola Wireless Switch Life Cycle Management
tools Plan and Procedures
ATE_COV.2 Analysis of coverage Motorola Wireless Switch Test Coverage Analysis
ATE_DPT.1 Testing: high-level design Motorola Wireless Switch Testing Plan and
Procedures
ATE_FUN.1 Functional testing Motorola Wireless Switch Testing Plan and
Procedures
ATE_IND.2 Independent testing - sample TOE for testing
Authentication Server
Audit Server
Time Server
Motorola Wireless Switch Testing Plan and
Procedures
AVA_MSU.2 Validation of analysis Motorola Wireless Switch Misuse Analysis
Motorola Wireless Switch CLI Reference Guide
AVA_SOF.1 Strength of TOE security Motorola Wireless Switch Strength of Function
function evaluation Analysis
Page 44 of 85
AVA_VLA.2 Independent vulnerability Motorola Wireless Switch Vulnerability Analysis
analysis
Page 45 of 85
7 PP Claims
The TOE conforms to the US Government Wireless Local Area Network (WLAN) Access System
Protection Profile for Basic Robustness Environments, Version 1.0, April 2006.
Please see Section 8.10, PP Claims Rationale, for a detailed discussion of PP compliance.
Page 46 of 85
8 Rationale
This section describes the rationale for the Security Objectives, Security Functional Requirements
and TOE Summary Specification. Additionally, this section describes the rationale for not satisfying
all of the dependencies and the rationale for the strength of function (SOF) claim. Table 8-1
illustrates the mapping from Security Objectives to Threats and Policies. It is identical to that of the
WLANAS PP.
8.1 Rationale for Security Objectives
Table 8-1 Security Objectives to Threats and Policies Mappings
Threat/Policy Objectives Addressing the Rationale

Threat
T.ACCIDENTAL_ADMIN_ O.ADMIN_GUIDANCE O.ADMIN_GUIDANCE helps to

ERROR mitigate this threat by ensuring
The TOE will provide
the TOE administrators have
An administrator may incorrectly administrators with the
guidance that instructs them
install or configure the TOE necessary information for
how to administer the TOE in a
resulting in ineffective security secure management.
secure manner. Having this
mechanisms.
O.MANAGE guidance helps to reduce the
The TOE will provide those mistakes that an administrator
functions and facilities might make that could cause
necessary to support the the TOE to be configured in a
administrators in their way that is insecure.
management of the security O.MANAGE also contributes to
of the TOE. mitigating this threat by
OE.NO_EVIL providing administrators the
capability to view and manage
Sites using the TOE shall configuration settings. For
ensure that administrators example, if the administrator
are non-hostile, appropriately made a mistake when
trained and follow all configuring the set of permitted
administrator guidance. users’ authentication
OE.NO_GENERAL_PURPO credentials, providing the
SE capability to view the lists of
authentication credentials
There are no general- affords them the ability to
purpose computing or review the list and discover any
storage repository mistakes that might have been
capabilities (e.g., compilers, made.
editors, or user applications)
available on the TOE. OE.NO_EVIL contributes to
mitigating this threat by
ensuring that the
administrators are non-hostile
Page 47 of 85
and are trained to appropriately
manage and administer the
TOE.
OE.NO_GENERAL_PURPOS
E also helps to mitigate this
threat by ensuring that there
can be no accidental errors
due to the introduction of
unauthorized software or data,
by ensuring that there are no
general-purpose or storage
repository applications
available on the TOE.
T.ACCIDENTAL_CRYPTO_COM O.RESIDUAL_INFORMATIO O.RESIDUAL_INFORMATION;
PROMISE N OE.RESIDUAL_INFORMATIO
N contributes to the mitigation
A user or process may cause key The TOE will ensure that any
of this threat by ensuring that
data or executable code information contained in a
any residual data is removed
associated with the cryptographic protected resource is not
from network packet objects
functionality to be inappropriately released when the resource
and ensuring that
accessed (viewed, modified or is reallocated.
cryptographic material is not
deleted), thus compromising the
OE.RESIDUAL_INFORMATI accessible once it is no longer
cryptographic mechanisms and
ON needed.
the data protected by those
mechanisms. The TOE IT environment will
ensure that any information
O.SELF_PROTECTION
contained in a protected
ensures that the TOE will have
resource within its Scope of
adequate protection from
Control is not released when
external sources and that all
the resource is reallocated.
TSP functions are invoked.
O.SELF_PROTECTION
The TOE will maintain a
OE.SELF_PROTECTION
domain for itself and the
ensures that the TOEIT
TOE’s own execution that
environment will have
protects them and their
protection similar to that of the
resources from external
TOE.
interference, tampering, or
unauthorized disclosure
through their interfaces.
OE.SELF_PROTECTION
The environment will
maintain a domain for its own
execution that protects itself
and its resources from
external interference,
tampering, or unauthorized
disclosure through its own
interfaces.
Page 48 of 85
T.MASQUERADE O.TOE_ACCESS O.TOE_ACCESS mitigates this

threat by controlling logical
A user may masquerade as an The TOE will provide
access to the TOE and its
authorized user or the mechanisms that control a
resources. By constraining how
authentication server to gain user’s logical access to the
and when authorized users can
access to data or TOE resources. TOE.
access the TOE, and by
OE.TOE_ACCESS mandating the type and
The environment will provide strength of the authentication
mechanisms that support the mechanism, this objective
TOE in providing users helps mitigate the possibility of
logical access to the TOE. a user attempting to login and
masquerade as an authorized
OE.TOE_NO_BYPASS user. In addition, this objective
Wireless clients are provides the administrator the
configured so that information means to control the number of
cannot flow between a failed login attempts a user can
wireless client and any other generate before an account is
wireless client or host locked out, further reducing the
networked to the TOE without possibility of a user gaining
passing through the TOE. unauthorized access to the
TOE. Finally, the TOE includes
requirements that ensure
protected channels are used to
authenticate wireless users
and to communicate with
critical portions of the TOE IT
environment.
OE.TOE_ACCESS supports
TOE authentication by
providing an authentication
server in the TOE IT
environment. The environment
also includes requirements that
ensure protected channels are
used to communicate with
critical portions of the TOE IT
environment.
OE.TOE_NO_BYPASS
contributes to mitigating this
threat by ensuring that wireless
clients must be configured for
all information can not be
flowing between a wireless
client and another client or
other host on the network
without passing through the
TOE.
Page 49 of 85
T.POOR_DESIGN O.CONFIGURATION_ O.CONFIGURATION_IDENTIF

IDENTIFICATION ICATION plays a role in
Unintentional errors in
countering this threat by
requirements specification or The configuration of the TOE
requiring the developer to
design of the TOE may occur, is fully identified in a manner
provide control of the changes
leading to flaws that may be that will allow implementation
made to the TOE’s design
exploited by a casually errors to be identified,
documentation and the ability
mischievous user or program. corrected with the TOE being
to report and resolve security
redistributed promptly.
flaws.
O.DOCUMENTED_ DESIGN
O.DOCUMENTED_DESIGN
The design of the TOE is counters this threat, to a
adequately and accurately degree, by requiring that the
documented. TOE be developed using
O.VULNERABILITY_ sound engineering principles.
ANALYSIS The use of a high level design
and the functional specification
The TOE will undergo ensure that developers
vulnerability analysis responsible for TOE
demonstrate the design and development understand the
implementation of the TOE overall design of the TOE. This
does not contain any obvious in turn decreases the likelihood
flaws. of design flaws and increases
the chance that accidental
design errors will be
discovered. ADV_RCR.1
ensures that the TOE design is
consistent across the High
Level Design and the
Functional Specification.
O.VULNERABILITY_ANALYSI
S_TEST ensures that the TOE
has been analyzed for obvious
vulnerabilities and that any
vulnerabilities found have been
removed or otherwise
mitigated, this includes
analysis of any probabilistic or
permutational mechanisms
incorporated into a TOE
claiming conformance to this
ST.
Page 50 of 85
T.POOR_IMPLEMENTATION O.CONFIGURATION_ O.CONFIGURATION_IDENTIF

IDENTIFICATION ICATION plays a role in
Unintentional errors in
countering this threat by
implementation of the TOE The configuration of the TOE
requiring the developer to
design may occur, leading to is fully identified in a manner
provide control of the changes
flaws that may be exploited by a that will allow implementation
made to the TOE’s design.
casually mischievous user or errors to be identified,
This ensures that changes to
program. corrected with the TOE being
the TOE are performed in
redistributed promptly.
structure manner and tracked.
O.PARTIAL_FUNCTIONAL_
O.PARTIAL_FUNCTIONAL_T
TESTING
ESTING ensures that the
The TOE will undergo some developers provide evidence
security functional testing that and demonstration that all
demonstrates the TSF security functions perform as
satisfies some of its security specified through independent
functional requirements. sample testing.
O.VULNERABILITY_ O.VULNERABILITY_ANALYSI
ANALYSIS S_TEST ensures that the TOE
The TOE will undergo has been analyzed and tested
vulnerability analysis to to demonstrate that it is
demonstrate the design and resistant to obvious
implementation of the TOE vulnerabilities.
does not contain any obvious
flaws.
T.POOR_TEST O.CORRECT_ O.CORRECT_
TSF_OPERATION TSF_OPERATION provides
The developer or tester performs
assurance that the TSF
insufficient tests to demonstrate The TOE will provide the
continues to operate as
that all TOE security functions capability to test the TSF to
expected in the field.
operate correctly (including in a ensure the correct operation
fielded TOE) may occur, resulting of the TSF at a customer’s O.PARTIAL_FUNCTIONAL_T
in incorrect TOE behavior being site. ESTING increases the
undiscovered leading to flaws that likelihood that any errors that
O.PARTIAL_FUNCTIONAL_
may be exploited by a do exist in the implementation
TESTING
mischievous user or program. will be discovered through
The TOE will undergo some testing.
security functional testing that
O.VULNERABILITY_ANALYSI
demonstrates the TSF
S_TEST addresses this
satisfies some of its security
concern by requiring a
functional requirements.
vulnerability analysis be
O.VULNERABILITY_ performed in conjunction with
ANALYSIS testing that goes beyond
The TOE will undergo some functional testing. This
vulnerability analysis objective provides a measure
demonstrate the design and of confidence that the TOE
implementation of the TOE does not contain security flaws
does not contain any obvious that may not be identified
flaws. through functional testing.
Page 51 of 85
O.DOCUMENTED_DESIGN.
O.DOCUMENTED_DESIGN
helps to ensure that the TOE's
The design of the TOE is documented design satisfies
adequately and accurately the security functional
documented. requirements. In order to
ensure the TOE's design is
correctly realized in its
implementation, the
appropriate level of functional
testing of the TOE's security
mechanisms must be
performed during the
evaluation of the TOE.
T.RESIDUAL_DATA O.RESIDUAL_ O.RESIDUAL_INFORMATION

INFORMATION and
A user or process may gain
TOE.RESIDUAL_INFORMATI
unauthorized access to data The TOE will ensure that any
ON contributes to the
through reallocation of TOE information contained in a
mitigation of this threat by
resources from one user or protected resource within its
ensuring that any residual data
process to another. Scope of Control is not
is removed from network
released when the resource
packet objects and ensuring
is reallocated.
that cryptographic material is
OE.RESIDUAL_INFORMATI not accessible once it is no
ON longer needed.
The TOE IT environment will
ensure that any information
contained in a protected
resource within its Scope of
Control is not released when
the resource is reallocated.
Page 52 of 85
T.TSF_COMPROMISE O.MANAGE O.MANAGE mitigate this threat

by restricting access to
A user or process may cause, The TOE will provide
administrative functions and
through an unsophisticated functions and facilities
management of TSF data to
attack, TSF data, or executable necessary to support the
the administrator.
code to be inappropriately administrators in their
accessed (viewed, modified, or management of the security OE.MANAGE ensures that the
deleted). of the TOE. administrator can view security
relevant audit events.
OE.MANAGE
O.RESIDUAL_INFORMATION
and
augment the TOE functions
OE.RESIDUAL_INFORMATIO
and facilities necessary to
N contributes to the mitigation
support the administrators in
of this threat by ensuring that
their management of the
any residual data is removed
security of the TOE, and
from network packet objects
restrict these functions and
and ensuring that
facilities from unauthorized
cryptographic material is not
use.
accessible once it is no longer
O.RESIDUAL_ needed.
INFORMATION
O.SELF_PROTECTION
The TOE will ensure that any requires that the TOE
information contained in a environment be able to protect
protected resource within its itself from tampering and that
Scope of Control is not the security mechanisms in the
released when the resource TOE cannot be bypassed.
is reallocated. Without this objective, there
OE.RESIDUAL_INFORMATI could be no assurance that
ON users could not view or modify
TSF data or TSF executables.
ensure that any information OE.SELF_PROTECTION
contained in a protected ensures that the TOE IT
resource within its Scope of environment will have
Control is not released when protection similar to that of the
the resource is reallocated. TOE.
O.SELF_PROTECTION
The TSF will maintain a
domain for its own execution
that protects itself and its
resources from external
interference, tampering, or
unauthorized disclosure
through its interfaces.
OE.SELF_PROTECTION
The environment will
maintain a domain for its own
execution that protects itself
Page 53 of 85
and its resources from
external interference,
tampering, or unauthorized
disclosure through its own
interfaces.
T.UNATTENDED_SESSION O.TOE_ACCESS The only sessions that are

established with the TOE are
A user may gain unauthorized The TOE will provide
anticipated to be administrative
access to an unattended session. mechanisms that control a
sessions. Hence, this threat is
user’s logical access to the
restricted to administrative
TOE.
sessions. The termination of
general user sessions is
expected to be handled by the
IT environment.
O.TOE_ACCESS helps to
mitigate this threat by including
mechanisms that place
controls on administrator
sessions. Administrator
sessions are dropped after an
Administrator defined time
period of inactivity. Dropping
the connection of a session
(after the specified time period)
reduces the risk of someone
accessing the machine where
the session was established,
thus gaining unauthorized
access to the session.
Page 54 of 85
T.UNAUTH_ADMIN_ACCESS O.ADMIN_GUIDANCE O.ADMIN_GUIDANCE helps to

mitigate this threat by ensuring
An unauthorized user or process The TOE will provide
the TOE administrators have
may gain access to an administrators with the
guidance that instructs them
administrative account. necessary information for
how to administer the TOE in a
secure management.
secure manner. Having this
O.MANAGE guidance helps to reduce the
The TOE will provide mistakes that an administrator
functions and facilities might make that could cause
necessary to support the the TOE to be configured in a
administrators in their way that is not secure.
management of the security O.MANAGE and OE.MANAGE
of the TOE, and restrict these mitigate this threat by
functions and facilities from restricting access to
unauthorized use. administrative functions and
OE.MANAGE management of TSF data to
the administrator.
augment the TOE functions O.TOE_ACCESS and
and facilities necessary to OE.TOE_ACCESS helps to
support the administrators in mitigate this threat by including
their management of the mechanisms to authenticate
security of the TOE, and TOE administrators and place
restrict these functions and controls on administrator
facilities from unauthorized sessions.
use. OE.NO_EVIL helps to mitigate
O.TOE_ACCESS this threat by ensuring that the
TOE administrators have
The TOE will provide guidance that instructs them in
mechanisms that control a how to administer the TOE in a
user’s logical access to the secure manner.
TOE.
OE.TOE_ACCESS
The environment will provide
mechanisms that support the
TOE in providing user’s
OE.NO_EVIL
Sites using the TOE shall
ensure that administrators
are non-hostile, appropriately
trained and follow all
administrator guidance.
Page 55 of 85
P.ACCESS_BANNER O.DISPLAY_BANNER O.DISPLAY_BANNER satisfies

The TOE shall display an initial The TOE will display an this policy by ensuring that the
banner describing restrictions of advisory warning regarding TOE displays an administrator
use, legal agreements, or any use of the TOE. configurable banner that
other appropriate information to provides all users with a
which users consent by warning about unauthorized
accessing the system. use of the TOE. A banner will
be presented for all TOE
services that allow direct
access to the TOE. In other
words, it will be required for all
administrative actions.
The presentation of banners
prior to actions that take place
as a result of the passing of
traffic through the TOE is
assumed to be provided by the
IT environment.
P.ACCOUNTABILITY O.AUDIT_GENERATION O.AUDIT_GENERATION

The authorized users of the TOE The TOE will provide the addresses this policy by
shall be held accountable for their capability to detect and providing the Administrator
actions within the TOE. create records of security- with the capability of
relevant events associated configuring the audit
with users. mechanism to record the
actions of a specific user, or
OE.AUDIT_PROTECTION
review the audit trail based on
The IT Environment will the identity of the user.
provide the capability to Additionally, the administrator’s
protect audit information and ID is recorded when any
the authentication security relevant change is
credentials. made to the TOE (e.g. access
OE.AUDIT_REVIEW rule modification, start-stop of
The IT Environment will the audit mechanism,
provide the capability to establishment of a trusted
selectively view audit channel, etc.).
information. OE.AUDIT_PROTECTION
O.MANAGE provides protected storage of
The TOE will provide TOE and IT environment audit
functions and facilities data in the environment.
necessary to support the OE.AUDIT_REVIEW Further
administrators in their supports accountability by
management of the security providing mechanisms for
of the TOE., and restrict viewing and sorting the audit
these functions and facilities logs
from unauthorized use. O.MANAGE ensures that
OE.MANAGE access to administrative
The TOE IT environment will functions and management of
TSF data is restricted to the
Page 56 of 85
augment the TOE functions administrator.
and facilities necessary to OE.MANAGE ensures that the
support the administrators in administrator can manage
their management of the audit functionality in the TOE
security of the TOE, and IT environment.
O.TIME_STAMPS plays a role
facilities from unauthorized
in supporting this policy by
use.
requiring the TOE to provide a
O.TIME_STAMPS reliable time stamp (via an
The TOE shall obtain reliable external NTP server).
time stamps and the
capability for the
The audit mechanism is
administrator to set the time
required to include the current
used for these time stamps.
date and time in each audit
OE.TIME_STAMPS record. All audit records that
The TOE IT environment include the user ID, will also
shall provide reliable time include the date and time that
stamps and the capability for the event occurred.
the administrator to set the OE.TIME_STAMPS ensures
time used for these time that the TOE IT environment
stamps. provides time services.
O.TOE_ACCESS O.TOE_ACCESS and
The TOE will provide OE.TOE_ACCESS support this
mechanisms that control a policy by controlling logical
user’s logical access to the access to the TOE and its
TOE. resources. This objective
OE.TOE_ACCESS ensures that users are
identified and authenticated so
The environment will provide
that their actions may be
mechanisms that support the
tracked by the administrator.
TOE in providing user’s
P.CRYPTOGRAPHIC O.CRYPTOGRAPHY O.CRYPTOGRAPHY satisfies
The TOE shall provide The TOE shall provide this policy by requiring the TOE
cryptographic functions for its cryptographic functions to to implement NIST FIPS
own use, including maintain the confidentiality validated cryptographic
encryption/decryption operations. and allow for detection of services. These services will
modification of user data that provide confidentiality and
is transmitted between integrity protection of TSF data
physically separated portions while in transit to remote parts
of the TOE, or outside of the of the TOE.
TOE. O.RESIDUAL_INFORMATION
O.RESIDUAL_ satisfies this policy by ensuring
INFORMATION that cryptographic data are
cleared according to FIPS 140-
The TOE will ensure that any
1/2.
information contained in a
protected resource within its
Scope of Control is not
released when the resource
Page 57 of 85
is reallocated.
P.CRYPTOGRAPHY_VALIDATE O.CRYPTOGRAPHY O.CRYPTOGRAPHY satisfies

D The TOE shall provide this policy by requiring the TOE
Only NIST FIPS validated cryptographic functions to to implement NIST FIPS
cryptography (methods and maintain the confidentiality validated cryptographic
implementations) are acceptable and allow for detection of services. These services will
for key management (i.e.; modification of user data that provide confidentiality and
generation, access, distribution, is transmitted between integrity protection of TSF data
destruction, handling, and storage physically separated portions while in transit to remote parts
of keys) and cryptographic of the TOE, or outside of the of the TOE.
services (i.e.; encryption, TOE. O.CRYPTOGRAPHY_VALIDA
decryption, signature, hashing, TED satisfies this policy by
key exchange, and random requiring that all cryptomodules
O.CRYPTOGRAPHY_VALID
number generation services). for cryptographic services be
ATED
NIST 140-1/2 validated. This
The TOE will use NIST FIPS will provide assurance that the
140-1/2 validated NIST-approved security
cryptomodules for functions and random number
cryptographic services generation will be in
implementing NIST-approved accordance with NIST and
security functions and validated according the FIPS
random number generation 140-1/2
services used by
cryptographic functions.
Page 58 of 85
P.ENCRYPTED_CHANNEL O.CRYPTOGRAPHY O.CRYPTOGRAPHY and

The TOE shall provide the The TOE shall provide O.CRYPTOGRAPHY_VALIDA
capability to encrypt/decrypt cryptographic functions to TED satisfy this policy by
wireless network traffic between maintain the confidentiality requiring the TOE to implement
the TOE and those wireless and allow for detection of NIST FIPS validated
clients that are authorized to join modification of user data that cryptographic services. These
the network. is transmitted between services will provide
physically separated portions confidentiality and integrity
of the TOE, or outside of the protection of TSF data while in
TOE. transit to wireless clients that
are authorized to join the
O.CRYPTOGRAPHY_VALID
network.
ATED
O.MEDIATE further allows the
The TOE will use NIST FIPS
TOE administrator to set a
140-1/2 validated
policy to encrypt all wireless
cryptomodules for
traffic.
cryptographic services
implementing NIST-approved OE.PROTECT_MGMT_COMM
security functions and S provides that the audit
random number generation records, remote network
services used by management information and
cryptographic functions. authentication data will be
protected by means of a
O.MEDIATE
protected channel in the
The TOE must mediate the environment.
flow of information to and
from wireless clients
communicating via the TOE
in accordance with its
security policy.
OE.PROTECT_MGMT_COM
MS
The environment shall protect
the transport of audit records
to the audit server, remote
network management, and
authentication server
communications with the
TOE in a manner that is
commensurate with the risks
posed to the network.
Page 59 of 85
P.NO_AD_HOC_NETWORKS O.MEDIATE O.MEDIATE works to support

In concordance with the DOD The TOE must mediate the this policy by ensuring that all
Wireless Policy, there will be no flow of information to and network packets that flow
ad hoc 802.11 or 802.15 from wireless clients through the TOE are subject to
networks allowed. communicating via the TOE the information flow policies.
in accordance with its OE.TOE_NO_BYPASS
security policy. supports this policy by
OE.TOE_NO_BYPASS ensuring that wireless clients
must be configured to use the
Wireless clients are
wireless access system for all
configured so that information
information flowing between a
cannot flow between a
wireless client and any other
wireless client and any other
host on the network. If the
wireless client or host
clients are properly configured,
networked to the TOE without
any information passing
passing through the TOE
through the TOE will be
inspected to ensure it is
authorized by TOE policies.
8.2 Rationale for Security Objectives in the TOE Environment
Four of the security objectives for the TOE are simply restatements of an assumption found in
Section 3.1. Therefore, these four objectives for the environment, OE.NO_EVIL, OE.PHYSICAL,
OE.NO_GENERAL_PURPOSE, and OE.TOE_NO_BYPASS trace to the assumptions trivially.
The remainder of the security objectives for the IT environment have been included in this ST in
order to support the TOE IT environment security functions. The rationale support is documented in
Table 8-1 Security Objectives to Threats and Policies Mappings along with the rationale for security
objectives for the TOE.
Page 60 of 85
8.3 Rationale for TOE Security Requirements
Table 8-2 Rationale for TOE Security Requirements
Objective Requirements Rationale

Addressing the
Objective
O.ADMIN_GUIDANCE ADO_DEL.1 ADO_DEL.1 ensures that the administrator
has the ability to begin their TOE installation
The TOE will provide ADO_IGS.1
with a clean (e.g., malicious code has not
administrators with the
AGD_ADM.1 been inserted once it has left the developer’s
necessary information for
AGD_USR.1 control) version of the TOE, which is
secure management.
necessary for secure management of the TOE
AVA_MSU.1
The ADO_IGS.1 requirement ensures the
administrator has the information necessary to
install the TOE in the evaluated configuration.
Often times a vendor’s product contains
software that is not part of the TOE and has
not been evaluated. The Installation,
Generation and Startup (IGS) documentation
ensures that once the administrator has
followed the installation and configuration
guidance the result is a TOE in a secure
configuration.
The AGD_ADM.1 requirement mandates the
developer provide the administrator with
guidance on how to operate the TOE in a
secure manner. This includes describing the
interfaces the administrator uses in managing
the TOE and any security parameters that are
configurable by the administrator. The
documentation also provides a description of
how to set up and use the auditing features of
the TOE.
The AGD_USR.1 is intended for non-
administrative users. If the TOE provides
facilities/interfaces for this type of user, this
guidance will describe how to use those
interfaces securely. This could include
guidance on the setup of wireless clients for
use with the TOE. If it is the case that the
Page 61 of 85
wireless clients may be configured by
administrators that are not administrators of
this TOE, then that guidance may be user
guidance from the perspective of this TOE.
AVA_MSU.1 ensures that the guidance
documentation can be followed
unambiguously to ensure the TOE is not
misconfigured in an insecure state due to
confusing guidance.
O.AUDIT_GENERATION FAU_GEN.1(1) FAU_GEN.1(1) defines the set of events that
the TOE must be capable of recording. This
The TOE will provide the FAU_GEN.2
requirement ensures that the administrator has
capability to detect and
FAU_SEL.1 the ability to audit any security relevant event
create records of security-
FIA_USB.1(1),(2) that takes place in the TOE. This requirement
relevant events associated
also defines the information that must be
with users. FPT_STM_EXP.1 contained in the audit record for each
FTP_ITC_EXP.1(1) auditable event. There is a minimum of
information that must be present in every audit
record and this requirement defines that, as
well as the additional information that must be
recorded for each auditable event. This
requirement also places a requirement on the
level of detail that is recorded on any
additional security functional requirements an
ST author adds to this ST.
FAU_GEN.2 ensures that the audit records
associate a user identity with the auditable
event. In the case ofauthorized users, the
association is accomplished with the user ID.
In all other cases, the association is based on
the source network identifier, which is
presumed to be the correct identity, but cannot
be confirmed since these subjects are not
authenticated.
FAU_SEL.1 allows for the selection of events
to be audited. This requires that the criteria
used for the selection of auditable events to be
defined. For example, the user identity can be
used as selection criterion for the events to be
audited.
FIA_USB.1(1),(2) play a role is satisfying this
objective by requiring a binding of security
attributes associated with users that are
authenticated with the subjects that represent
them in the TOE. This only applies to
authorized users, since the identity of
unauthenticated users cannot be confirmed.
Therefore, the audit trail may not always have
Page 62 of 85
the proper identity of the subject that causes
an audit record to be generated (e.g.,
presumed network address of an
unauthenticated user may be a spoofed
address).
FPT_STM_EXP.1 supports the audit
functionality by ensuring that the TOE is
capable of obtaining a time stamp for use in
recording audit events.
FTP_ITC_EXP.1(1) provides a trusted channel
for services provided by the TOE IT
environment (the audit server and the time
server).
O.CONFIGURATION_ ACM_CAP.2
ACM_CAP.1 contributes to this objective by
IDENTIFICATION ACM_SCP.1
requiring the developer have a configuration
The configuration of the ALC_FLR.2
management plan that describes how changes
TOE is fully identified in a
to the TOE and its evaluation deliverables are
manner that will allow
managed.
implementation errors to
be identified, corrected ACM_SCP.1 is necessary to define the items
with the TOE being that must be under the control of the CM
redistributed promptly. system. This requirement ensures that the
TOE implementation representation, design
documentation, test documentation (including
the executable test suite), user and
administrator guidance, and CM
documentation are tracked by the CM system.
ALC_FLR.2 plays a role in satisfying this
objective by requiring the developer to have
procedures that address flaws that have been
discovered in the product, either through
developer actions (e.g., developer testing) or
discovery by others. The flaw remediation
process used by the developer corrects any
discovered flaws and performs an analysis to
ensure new flaws are not created while fixing
the discovered flaws.
Page 63 of 85
O.CORRECT_ FPT_TST_EXP.1
FPT_TST_EXP.1 is necessary to ensure the
TSF_OPERATION FPT_TST_EXP.2
correct operation TSF hardware. If TSF
The TOE will provide the
software is corrupted it is possible that the
capability to test the TSF to
TSF would no longer be able to enforce the
ensure the correct
security policies. This also holds true for TSF
operation of the TSF at a
data, if TSF data is corrupt the TOE may not
customer’s site.
correctly enforce its security policies. The
FPT_TST_EXP.2 functional requirement
addresses the critical nature and specific
handling of the cryptographic related TSF
data. Since the cryptographic TSF data has
specific FIPS PUB requirements associated
with them it is important to ensure that any
fielded testing on the integrity of these data
maintains the same level of scrutiny as
specified in the FCS functional requirements.
O.CRYPTOGRAPHY FCS_BCM_EXP.1
The FCS requirements satisfy this objective by
The TOE shall provide FCS_CKM.1
levying requirements that ensure the
cryptographic functions to FCS_CKM_EXP.2
cryptographic standards include the NIST
maintain the confidentiality FCS_CKM.4
FIPS publications (wherepossible) and NIST
and allow for detection of FCS_COP_EXP.1
approved ANSI standards. The intent is to
modification of user data FCS_COP_EXP.2
have the satisfaction of the cryptographic
that is transmitted between
standards be validated through a NIST FIPS
physically separated
140-1/2 validation.
portions of the TOE, or
outside of the TOE. FCS_BCM_EXP.1 is an explicit requirement
that specifies the NIST FIPS rating level that
the cryptographic module must satisfy. The
level specifies the degree of testing of the
module. The higher the level, the more
extensively the module is tested.
FCS_CKM.1 ensures that, if necessary, the
TOE is capable of generating cryptographic
keys.
FCS_CKM_EXP.2 Cryptographic Key
Handling and Storage requires that FIPS PUB
140-1/2 be satisfied when performing key
entry and output.
FCS_CKM.4 mandates the standards (FIPS
140-1/2) that must be satisfied when the TOE
performs Cryptographic Key Zeroization.
FCS_COP_EXP.1 requires that a NIST
approved random number generator is used.
FCS_COP_EXP.2 requires for data decryption
and encryption that a NIST approved algorithm
is used, and that the algorithm meets the FIPS
PUB 140-1/2 standard.
Page 64 of 85
FCS_BCM_EXP.1
O.CRYPTOGRAPHY_VAL The FCS requirements satisfy this objective by
FCS_CKM.1
IDATED levying requirements that ensure the
FCS_CKM_EXP.2
cryptographic standards include the NIST
The TOE will use NIST FCS_CKM.4
FIPS publications (wherepossible) and NIST
FIPS 140-1/2 validated FCS_COP_EXP.1
approved ANSI standards. The intent is to
cryptomodules for
FCS_COP_EXP.2 have the satisfaction of the cryptographic
cryptographic services
standards be validated through a NIST FIPS
implementing NIST-
140-1/2 validation.
approved security
functions and random FCS_BCM_EXP.1 is an explicit requirement
number generation that specifies the NIST FIPS rating level that
services used by the cryptographic module must satisfy. The
cryptographic functions. level specifies the degree of testing of the
module. The higher the level, the more
extensively the module is tested.
FCS_CKM.1 ensures that, if necessary, the
TOE is capable of generating cryptographic
keys.
FCS_CKM_EXP.2 Cryptographic Key
Handling andStorage requires that FIPS PUB
140-1/2 be satisfied when performing key
entry and output.
FCS_CKM.4 mandates the standards (FIPS
140-1/2) that must be satisfied when the TOE
performs Cryptographic Key Zeroization.
FCS_COP_EXP.1 requires that a NIST
approved random number generator is used.
FCS_COP_EXP.2 requires for data decryption
and encryption that a NIST approved algorithm
is used, and that the algorithm meets the FIPS
PUB 140-1/2 standard.
O.DISPLAY_BANNER FTA_TAB.1 FTA_TAB.1 meets this objective by requiring
that the TOE display an administrator defined
The TOE will display an
banner before a user can establish an
advisory warning regarding
authenticated session. This banner is under
use of the TOE prior to
complete control of the administrator, who can
permitting the use of any
specify any warnings regarding unauthorized
TOE services that require
use of the TOE and remove any product or
authentication.
version information if they desire. The only
time that it is envisioned that an authenticated
session would need to be established is for the
performance of TOE administration. Bannering
is not necessary prior to use of services that
pass network traffic through the TOE.
Page 65 of 85
O.DOCUMENTED_DESIG ADV_FSP.1 ADV_FSP.1, ADV_HLD.1, and ADV_RCR.1

N support this objective by requiring that the
ADV_HLD.1
TOE be developed using sound engineering
ADV_RCR.1 principles. The use of a high level design and
the functional specification ensure that
developers responsible for TOE development
understand the overall design of the TOE. This
in turn decreases the likelihood of design flaws
and increases the chance that
accidentaldesign errors will be discovered.
ADV_RCR.1 ensures that the TOE design is
consistent across the High Level Design and
the Functional Specification.
O.MANAGE FMT_MOF.1(1) The FMT requirements are used to satisfy this

management objective, as well as other
The TOE will provide all FMT_MOF.1(2)
objectives that specify the control of
the functions and facilities
FMT_MOF.1(3) functionality. The requirements’ rationale for
necessary to support the
FMT_MSA.2 this objective focuses on the administrator’s
administrators in their
capability to perform management functions in
management of the FMT_MTD.1(1) order to control the behavior of security
security of the TOE, and
FMT_MTD.1(2) functions.
facilities from unauthorized FMT_MTD.1(3) FMT_MOF.1(1)(2) and (3) ensure that the
use. administrator has the ability manage the
FMT_SMR.1(1) cryptographic, audit, and authentication
FMT_SMF.1(1) functions.
FMT_SMF.1(2) FMT_MSA.2 provides the administrator the

ability to accept only secure values and modify
FMT_SMF.1(3) security attributes.
FMT_MTD.1(1) (2) and (3) ensure that the
administrator can manage TSF data. This ST
specifically identifies audit preselection,
identification, and authentication data.
FMT_SMR.1 defines the specific security roles
to be supported.
FMT_SMF.1(1), (2), and (3) support this
objective by identifying the management
functions for cryptographic data, audit records,
and cryptographic key data.
O.MEDIATE
FIA_UAU.1 FIA_UAU.1, FIA_UAU_EXP.5(1) and
The TOE must mediate the
FIA_UID.2 ensure that the TOE has the ability
flow of information to and FIA_UAU_EXP.5(1)
to mediate packet flow based upon the
from wireless clients FIA_UID.2 authentication credentials of the wireless user.
communicating via the
TOE RF FDP_PUD_EXP.1 allows the administrator to
FDP_PUD_EXP.1
Transmitter/Receiver control whether or not unencrypted data will be
Page 66 of 85
interface in accordance allowed to pass through the TOE.
with its security policy.
O.PARTIAL_FUNCTIONA ATE_COV.1 ATE_FUN.1 requires the developer to provide

L_TESTING ATE_FUN.1 the necessary test documentation to allow for
The TOE will undergo ATE_IND.2 an independent analysis of the developer’s
some security functional security functional test coverage. In addition,
testing that demonstrates the developer must provide the test suite
the TSF satisfies some of executables and source code, which the
its security functional evaluator uses to independently verify the
requirements. vendor test results and to support of the test
coverage analysis activities.
ATE_COV.1 requires the developer to provide

a test coverage analysis that demonstrates the
extent to which the TSFI are tested by the
developer’s test suite. This component also
requires an independent confirmation of the
extent of the test suite, which aids in ensuring
that correct security relevant functionality of a
TSFI is demonstrated through the testing
effort.
ATE_IND.2 requires an independent

confirmation of the developer’s test results by
mandating that a subset of the test suite be
run by an independent party. This component
also requires an independent party to craft
additional functional tests that address
functional behavior that is not demonstrated in
the developer’s test suite. Upon successful
completion ofthese requirements, the TOE’s
conformance to the specified security
functional requirements will have been
demonstrated.
Page 67 of 85
O.RESIDUAL_ FDP_RIP.1(1)
FDP_RIP.1 is used to ensure the contents of
INFORMATION FCS_CKM_EXP.2
resources are not available once the resource
FCS_CKM.4
is reallocated. For this TOE it is critical that the
The TOE will ensure that
memory used to build network packets is
any information contained
either cleared or that some buffer
in a protected resource
management scheme be employed to prevent
within its Scope of Control
the contents of a packet being disclosed in a
is not released when the
subsequent packet (e.g., if padding is used in
resource is reallocated.
the construction of a packet, it must not
contain another user’s data or TSF data).
FCS_CKM_EXP.2 places requirements on
how cryptographic keys are managed within
the TOE. This requirement places restrictions
in addition to FDP_RIP.1, in that when a
cryptographic key is moved from one location
to another (e.g., calculated in some scratch
memory and moved to a permanent location)
that the memory area is immediately cleared
as opposed to waiting until the memory is
reallocated to another subject.
FCS_CKM.4 applies to the destruction of
cryptographic keys used by the TSF. This
requirement specifies how and when
cryptographic keys must be destroyed. The
proper destruction of these keys is critical in
ensuring the content of these keys cannot
possibly be disclosed when a resource is
reallocated to a user.
O.SELF_PROTECTION FPT_SEP.1(1) FPT_SEP.1(1) was chosen to ensure the TSF
provides a domain that protects itself from
The TSF will maintain a FPT_RVM.1(1)
untrusted users. If the TSF cannot protect
domain for its own
itself it cannot be relied upon to enforce its
execution that protects
security policies.
itself and its resources
from external interference, FPT_RVM.1(1) ensures that the TSF makes
tampering, or unauthorized policy decisions on all interfaces that perform
disclosure. operations onsubjects and objects that are
within the scope of the policies. Without this
non-bypassability requirement,the TSF could
not be relied upon to completely enforce the
security policies, since an interface(s) may
otherwise exist that would provide a user with
access to TOE resources (including TSF data
and executable code) regardless of the
defined policies. This includes controlling the
accessibility to interfaces, as well as what
access control is provided within the
interfaces.
Page 68 of 85
O.TIME_STAMPS FPT_STM_EXP.1 FPT_STM_EXP.1 requires that the TOE be

able to obtain reliable time stamps for its own
The TOE shall obtain
use and therefore, partially satisfies this
reliable time stamps from
objective. Time stamps include date and time
the IT Environment and the
and are reliable in that they are always
capability for the
available to the TOE, and the clock must be
administrator to set the
monotonically increasing.
time used for these time
stamps.
O.TOE_ACCESS FIA_AFL.1(1) FIA_UID.2 plays a role in satisfying this
objective by ensuring that every user is
The TOE will provide FIA_ATD.1(1)
identified before the TOE performs any
mechanisms that control a
FIA_UAU.1 mediated functions. In most cases, the
user’s logical access to the
FIA_UAU_EXP.5(1) identification cannot be authenticated (e.g.,a
TOE.
user attempting to send a data packet through
FIA_UID.2 the TOE that does not require authentication.
AVA_SOF.1 It is impractical to require authentication of all
users that attempt to send data through the
FTA_SSL.3 TOE, therefore, the requirements specified in
FTP_TRP1 the TOE require authentication where it is
deemed necessary. This does impose some
FTP_ITC_EXP.1(1) risk that a data packet was sent from an
identity other than that specified in the data
packet.
AVA_SOF.1 requires that any permutational or
probabilistic mechanism in the TOE be
analyzed and found to be resistant to attackers
possessing a “low” attack potential. This
provides confidence that security mechanisms
vulnerable to guessing type attacks are
resistant to casual attack.
FIA_UAU.1 and FIA_UAU_EXP.5(1)
contribute to thisobjective by ensuring that
administrators and users are authenticated
before they are provided access to the TOE or
its services.
In order to control logical access to the TOE
an authentication mechanism is required. The
local administrator authentication mechanism
is necessary to ensure an administrator has
the ability to login to the TOE regardless of
network connectivity (e.g., it would be
unacceptable if an administrator could not
login to the TOE because the authentication
server was down, or that the network path to
the authentication server was unavailable).
FIA_AFL.1(1) ensures that the TOE can
protect itself and its users from brute force
Page 69 of 85
attacks on their authentication credentials.
FIA_ATD.1(1) Management requirements
provides additional control to supplement the
authentication requirements.
FTA_SSL.3 ensures that inactive user and
administrative sessions are dropped.
FTP_TRP.1 ensures that remote users have a
trusted path in order to authenticate.
FTP_ITC_EXP.1(1) provides a trusted channel
for services provided by the TOE IT
environment (the remote authentication
server)
O.VULNERABILITY_ AVA_VLA.1
AVA_VLA.1 requires the developer to perform
ANALYSIS AVA_SOF.1
a search for obvious vulnerabilities in all the
The TOE will undergo
TOE deliverables. The developer must then
some vulnerability analysis
document the disposition of those obvious
demonstrate the design
vulnerabilities. The evaluator then builds upon
and implementation of the
this analysis during vulnerability testing. This
TOE does not contain any
component provides the confidence that
obvious flaws.
obvious security flaws have been either
removed from the TOE or otherwise mitigated.
AVA_SOF.1 requires that any permutational or
probabilistic mechanism in the TOE be
analyzed be found to be resistant to attackers
possessing a “low” attack potential. This
provides confidence that security mechanisms
vulnerable to guessing type attacks are
resistant to casual attack.
8.4 Rationale for TOE IT Environment Security Requirements
Table 8-3 Rationale for Requirements on the TOE IT Environment
Objective Requirements Rationale

Addressing the
Objective
Page 70 of 85
OE.AUDIT_PROTECTION FAU_SAR.2
FAU_SAR.2 restricts the ability to read the
FAU_STG.1
audit records to only the administrator. The
The IT Environment will FAU_STG.3
exception to this is that all administrators have
provide the capability to FMT_MOF.1(4)
access to the audit record information
protect audit information FMT_SMR.1(2)
presented in the alarm indicating a potential
and the authentication
security violation.
credentials.
FAU_STG.1restricts the ability to delete or
modify audit information to the administrators.
The TSF will prevent modifications of the audit
records in the audit trail.
FAU_STG.3 ensures that the administrator will
take actions when the audit trail exceeds pre-
defined limits.
FMT_MOF.1(4) and FMT_SMR.1(2) specify
the ability of the administrators to control the
security functions associated with audit and
alarm generation. The ability to control these
functions has been assigned to the
appropriate administrative roles.
OE.AUDIT_REVIEW FAU_GEN.1(2) FAU_SAR.1 ensures that the IT environment

FAU_SAR.1 provides those responsible for the TOE with
The IT Environment will FAU_SAR.3 facilities to review the TOE audit records (e.g.,
provide the capability to the administrator can construct a sequence of
selectively view audit events provided the necessary events were
information. audited).
FAU_SAR.3 provides the administrator with
the ability to selectively review the contents of
the audit trail based on established criteria.
This capability allows the administrator to
focus their audit review to what is pertinent at
that time.
FAU_GEN.1 ensures that the TOE IT
environment will generate appropriate audit
events to support the TOE.
OE.MANAGE FMT_MOF.1(4) FIA_USB.1 ensures that the TOE IT
environment includes a mechanism to
The TOE IT environment FMT_SMR.1(2)
associate processes with roles. This ensures
will augment the TOE FMT_MTD.1(3),(4),
that both the TOE and its IT environment can
functions and facilities (5)
identify
necessary to support the FMT_SMF.1(4),(5)
administrators in their FMT_MOF.1(4) ensures that the TOE IT
management of the environment limits access to TSF
security of the TOE, and management functions to the administrator.
restrict these functions and FMT_SMR.1(2), FMT_MTD.1(3),(4), (5)
facilities from unauthorized FMT_SMF.1(4),(5) ensure that the TOE IT
use. environment provides an administrative role
and management functions that may be used
Page 71 of 85
to manage the IT environment.
OE.NO_EVIL AGD_ADM.1
The AGD_ADM.1 requirement mandates the
Sites using the TOE shall
developer provide the administrator with
ensure that administrators
guidance on how to operate the TOE in a
are non-hostile,
secure manner. This includes describing the
appropriately trained and
interfaces the administrator uses in managing
follow all administrator
the TOE and any security parameters that are
guidance.
configurable by the administrator. The
documentation also provides a description of
how to setup and review the auditing features
of the TOE.
OE.NO_GENERAL_PURP A.NO_GENERAL_P
It is assumed that there will be no general-
OSE URPOSE
purpose computing or storage capabilities
available on the TOE therefore no SFR is
There are no general-
necessary.
purpose computing or
storage repository
capabilities (e.g.,
compilers, editors, or user
applications) available on
the TOE.
OE.PHYSICAL A.Physical Physical security, commensurate with the

value of the TOE and the data it contains, is
The IT environment assumed to be provided by the IT
provides physical security, environment. Therefore, an explicit
commensurate with the requirement is not necessary.
value of the TOE and the
data it contains.
OE.PROTECT_MGMT_CO FTP_ITC_EXP.1(2) FTP_ITC_EXP.1(2) provides a trusted channel

MMS for services provided by the TOE IT
environment to the TOE (the remote
The environment shall authentication server, syslog serverand time
protect the transport of server)
audit records to the audit
server, remote network
management, and
authentication server
communications with the
Page 72 of 85
TOE in a manner that is
commensurate with the
risks posed to the network.
OE.RESIDUAL_INFORMA FDP_RIP.1(2) FDP_RIP.1(2) ensures that the TOE IT

TION environment provides same protections for
The TOE IT environment residual information in a network packet that
will ensure that any the TOE will provide. This ensures that neither
information contained in a the TOE nor the TOE IT environment will allow
protected resource within data from previously transmitted packets to be
its Scope of Control is not insert into new packets.
released when the
resource is reallocated.
OE.SELF_PROTECTION FPT_SEP.1(2) The TOE IT environment must protect itself in

The IT environment will FPT_RVM.1(2) a manner similar to that provided for the TOE.
maintain a domain for its FPT_SEP.1(2) ensures the environment
own execution that protects provides a domain that protects itself from
itself and its resources untrusted users. If the environment cannot
from external interference, protect itself it cannot be relied upon to
tampering, or unauthorized enforce its security policies. FPT_RVM.1(2)
disclosure through its own ensures that the environment makes policy
interfaces. decisions on all interfaces that perform
operations on subjects and objects that are
scoped by the policies.
OE.TOE_ACCESS FIA_AFL.1(2) The TOE IT environment will provide a remote
The environment will FIA_ATD.1(2) authentication mechanism in order to support
provide mechanisms that FIA_UAU_EXP.5(2) TOE authentication of users.
support the TOE in FIA_UID.1 FIA_UAU_EXP.5(2) and FIA_UID.1 ensure
providing user’s logical that users are identified and authenticated.
access to the TOE.
FIA_ATD.1(2) and FIA_AFL.1(2) ensure that
the proper attributes are associated with users
and that authentication failure is handled
properly.
OE.TOE_NO_BYPASS
FIA_UAU.1 FIA_UAU.1, FIA_UAU_EXP.5(2), and
FIA_UID.1 ensure that the TOE has the ability
Wireless clients are FIA_UAU_EXP.5(2)
to mediate packet flow based upon the
configured so that FIA_UID.1 authentication credentials of the wireless user.
information cannot flow
between a wireless client
and any other wireless
client or host networked to
the TOE without passing
through the TOE.
Page 73 of 85
OE.TIME_STAMPS FPT_STM.1 FPT_STM.1 requires that the TOE IT
The TOE IT environment environment be able to provide reliable time
FMT_MTD.1(5)
shall provide reliable time stamps for its own use and that of the TOE.
stamps and the capability Time stamps include date and time and are
for the administrator to set reliable in that they are always available to the
the time used for these TOE, and the clock must be monotonically
time stamps. increasing.
FMT_MTD.1(5) helps satisfy this objective by
providing that there be a management function
of the Security Administrator or an authorized
IT entity that will set the time and date used to
provide reliable time stamps to the TOE.
8.5 Rationale for Assurance Requirements
CC part 3 states:
“EAL4 permits a developer to gain maximum assurance from positive security engineering based
on good commercial development practices which, though rigorous, do not require substantial
specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be
economically feasible to retrofit to an existing product line.”
“EAL4 is therefore applicable in those circumstances where developers or users require a moderate
to high level of independently assured security in conventional commodity TOEs and are prepared
to incur additional security-specific engineering costs.”
Evaluation Assurance Level EAL4 augmented with ALC_FLR.2 in this ST was chosen based on the
security environment and the security objectives defined in this ST. Due to the nature of wireless
communications the TOE interacts with potentially hostile wireless environment, where any
malicious entity can potentially attack the TOE. Compared to wired networks, where physical
access to the network is usually limited to some extent, this amounts to an additional degree of risk
and justifies evaluating the TOE at EAL4.
The explicitly stated TOE security functional requirements in this ST are those of the WLANAS PP.
All assurance requirements specified in the WLANAS PP have been included in this ST. Therefore,
the assurance requirements of this ST cover the explicitely stated TOE security functional
requirements stated in this ST.
Evaluating the TOE at EAL4 is consistent with the current best IT security practices and provides a
degree of assurance matching that of other evaluated competitive products.
ALC_FLR.2 (Flaw Remediation) was added to EAL4 requirements to match the WLANAS PP.
Therefore, the assurance requirements of this ST match or exceed the requirements of WLANAS
PP in all assurance areas.
8.6 Satisfaction of Dependencies

Each functional requirement, including explicit requirements was analyzed to determine that all
dependencies were satisfied. All requirements were then analyzed to determine that no additional
Page 74 of 85
dependencies were introduced as a result of completing each operation. With the exception of
dependencies related to FMT_MSA.2, all dependencies in this ST have been satisfied.
FMT_MSA.2 is included in this ST as a dependency of the Cryptographic Support family
(FCS_COP and FCS_CKM). It is used there to ensure that security attributes related to
cryptographic objects (e.g. cryptographic keys) are protected. However, FMT_MSA family is also
used to ensure the protection of security attributes related to access control policies (FDP_IFC and
FDP_AFC) and includes a dependency upon those Security Functional Requirements. However,
this ST and WLANAS PP do not require that the TOE implement an access control policy and those
requirements have not been included in the ST.
FCS_CKM.1 depends on FCS_CKM.2 or FCS_COP.1, which are not included in this ST. Instead,
FCS_CKM_EXP.2 and FCS_COP_EXP.2 are included, which cover the requirements of
FCS_CKM.2 and FCS_COP.1. FAU_GEN.1 depends on FPT_STM.1, which is not included in this
ST. Instead, FPT_STM.1_EXP.1 is included, which covers the requirements of FPT_STM.1.
The satisfaction of dependencies in this ST is identical to the satisfaction of dependencies in
WLANAS PP.
8.7 Rationale for Strength of Function Claims

Part 1 of the CC defines “strength of function” in terms of the minimum efforts assumed necessary
to defeat the expected security behavior of a TOE security function. There are three strength of
function levels defined in Part 1: SOF-basic, SOF-medium and SOF-high. SOF-basic is the strength
of function level chosen for this ST. SOF-basic states, “a level of the TOE strength of function
where analysis shows that the function provides adequate protection against casual breach of TOE
security by attackers possessing a low attack potential.” The rationale for choosing SOF-basic was
to be consistent with the TOE objective O.VULNERABILITY_ANALYSIS and assurance
requirements included in this ST. Specifically, AVA_VLA.1 requires that the TOE be resistant to
obvious vulnerabilities. This is consistent with SOF-basic, which is the lowest strength of function
metric. Consequently, security functions with probabilistic or permutational mechanisms chosen for
inclusion in this ST were determined to adequately protect information in a Basic Robustness
Environment.
The password used for administrator authentication is the only probabilistic or permutational
mechanism implemented by the TOE. This mechanism is associated with the Identification and
Authentication security function. The TOE requires the administrator password to be at least 8
characters long. Numeric, alphabetic, and extended characters can be used, which gives a total of
95 characters. Therefore, the number of potential eight-character passwords is very significant.
The SOF claims of this ST match those of WLANAS PP.
8.8 Rationale for Explicit requirements

Table 8-4 Rationale for Explicit Requirements presents the rationale for the inclusion of the explicit
requirements found in this ST. The rationale matches that of WLANAS PP. The explicit
requirements are reproduced from the WLANAS PP and are left unchanged to maintain compliance
to the protection profile.
Table 8-4 Rationale for Explicit Requirements
Page 75 of 85
Explicit Requirement Identifier Rationale
FCS_BCM_EXP.1 Baseline This explicit requirement is necessary since the CC does

cryptographic not provide a means to specify a cryptographic baseline
module of implementation.
FCS_CKM_EXP.2 Cryptographic This explicit requirement is necessary since the CC does

key handling not specifically provide components for key handling and
and storage storage.
FCS_COP_EXP.1 Random This explicit requirement is necessary since the CC

number cryptographic operation components address only
generation specific algorithm types and operations requiring specific
key sizes. FCS_COP_EXP.1 requires FIPS approved
random number generation to be used for all
cryptographic functionalities, while FCS_CKM.1 is limited
to cryptographic key generation.
FCS_COP_EXP.2 Cryptographic This explicit requirement is necessary because it

Operation describes requirements for a cryptomodule rather than
the entire TSF.
FDP_PUD_EXP.1 Protection of This explicit requirement is necessary because the

User Data Common Criteria IFC/AFC requirements do not
accommodate access control policies that are not
object/attribute based. The FDP_PUP_EXP.1
requirement allows the administrator allow or disallow
access based upon an administrator setting indicating
whether or not unencrypted data may transit the wireless
LAN.
Page 76 of 85
FIA_UAU_EXP.5(1), Multiple This explicit requirement is needed for local

(2) authentication administrators because there is concern over whether or
mechanisms not existing CC requirements specifically require that the
TSF provide authentication. Authentication provided by
the TOE is implied by other FIA_UAU requirements and
is generally assumed to be a requirement when other
FIA_UAU requirements are included in a TOE. In order to
remove any potential confusion about this ST, an explicit
requirement for authentication has been included. This
ST also requires the IT environment to provide an
authentication server to be used for authentication of
remote users. It is important to specify that the TSF must
provide the means for local administrator authentication
in case the TOE cannot communicate with the
authentication server. In addition, the TOE must provide
the portions of the authentication mechanism necessary
to obtain and enforce an authentication decision from the
IT environment.
FPT_TST_EXP.1 TSF Testing This explicit requirement is necessary because, as

identified in the US Government PP Guidance for Basic
Robustness, there are several issues with the CC version
of FPT_TST.1. First, the wording of FPT_TST.1.1
appears to make sense only if the TOE includes
hardware; it is difficult to imagine what software TSF
“self-tests” would be run. Secondly, some TOE data are
dynamic (e.g., data in the audit trail, passwords) and so
interpretation of “integrity” for FPT_TST.1.2 is required,
leading to potential inconsistencies amongst Basic
Robustness TOEs. Therefore, the explicit requirements
are used in this ST.
FPT_TST_EXP.2 Testing of This explicit requirement is necessary because the basic

cryptographic self test requirement does not specify the required
modules elements for testing of cryptographic functions, as called
out in this explicit requirement.
FTP_ITC_EXP.1(1), Inter-TSF This explicit requirement is necessary because the

(2) trusted channel existing trusted channel requirement is written with the
intent of protecting communication between distributed
portions of the TOE rather than between the TOE and its
trusted IT environment.
Page 77 of 85
8.9 TOE Summary Specification Rationale
The TOE Summary Specification describes security functions of the TOE. The security functions
considered together satisfy all of the TSFRs and security assurance requirements. All of the
security functions are required in order for the TOE to support the required security functionalities.
The table below demonstrates the relationship of TSFRs to security functions.
Table 8-5 Mapping of Security Functions to TSFRs
Trusted Path/Channels
Cryptographic Support
Security Management
Protection of the TSF

User Data Protection
Identification and
Authentication
Security Audit
TOE Access
FAU_GEN.1(1) X
FAU_GEN.2 X
FAU_SEL.1 X
FCS_BCM_EXP.1 X
FCS_CKM.1 X
FCS_CKM_EXP.2 X
FCS_CKM.4 X
FCS_COP_EXP.1 X
FCS_COP_EXP.2 X
FDP_PUD_EXP.1 X
FDP_RIP.1(1) X
FIA_AFL.1(1) X
FIA_ATD.1(1) X
FIA_UAU.1 X
FIA_UAU_EXP.5(1) X
FIA_UID.2 X
FIA_USB.1 X
Page 78 of 85
FMT_MOF.1(1) X
FMT_MOF.1(2) X
FMT_MOF.1(3) X
FMT_MSA.2 X
FMT_MTD.1(1) X
FMT_MTD.1(2) X
FMT_SMF.1(1) X
FMT_SMF.1(2) X
FMT_SMF.1(3) X
FMT_SMR.1(1) X
FPT_RVM.1(1) X
FPT_SEP.1(1) X
FPT_STM_EXP.1 X
FPT_TST_EXP.1 X
FPT_TST_EXP.2 X
FTA_SSL.3 X
FTA_TAB.1 X
FTP_ITC_EXP.1(1) X
FTP_TRP.1 X
Page 79 of 85
The table below demonstrates suitability of Security Functions to meet TSFRs.
Table 8-6 Suitability of Security Functions to meet TSFRs
Security Functions SFRs Rationale

Security Audit FAU_GEN.1(1) The Security Audit function
enables TOE to generate audit
FAU_GEN.2
events (FAU_GEN.1(1)) that
FAU_SEL.1 contain the username for an
identified user (FAU_GEN.2),
and allows inclusion/exclusion
of events (FAU_SEL.1).
Cryptographic Support FCS_BCM_EXP.1 The Cryptographic Support
function ensures that the TOE
FCS_CKM.1
cryptographic module complies
FCS_CKM_EXP.2 with FIPS 140-2 at Level 2
FCS_CKM.4 (FCS_BCM_EXP.1). The
module generates
FCS_COP_EXP.1 cryptographic keys and random
FCS_COP_EXP.2(1) numbers (FCS_CKM.1 and
FCS_COP_EXP.1), supports
FCS_COP_EXP.2(2) cryptographic key
establishment
(FCS_CKM_EXP.2), allows
cryptographic key destruction
(FCS_CKM.4), and performs
cryptographic operations
(FCS_COP_EXP.1,
FCS_COP_EXP.2(1), and
FCS_COP_EXP.2(2)).
User Data Protection FDP_PUD_EXP.1 The User Data Protection
function ensures protection of
FDP_RIP.1(1)
the TOE wireless user data
(FDP_PUD_EXP.1) and
network packet residual
information (FDP_RIP.1(1)).
Identification and FIA_AFL.1(1) The Identification and
Authentication Authentication function ensures
FIA_ATD.1(1)
that the TOE prevents remote
FIA_UAU.1 administrator login when a
FIA_UAU_EXP.5(1) configurable number of
unsuccessful remote
FIA_UID.2 administrator authentication
FIA_USB.1(1) attempts occur (FIA_AFL.1(1)),
and maintains administrator
FIA_USB.1(2) passwords (FIA_ATD.1(1)).
The TOE enforces user
Page 80 of 85
authentictation before any
actions other than identification
(FIA_UAU.1).
The TOE authenticates
administrators using passwords
while wireless LAN users are
authenticated using the EAP
protocol (FIA_UAU_EXP.5(1)).
The TOE requires that each
user must be successfully
identified before allowing TSF-
mediated actions (FIA_UID.2).
The TOE associates a
username with a subject acting
on the user’s behalf upon
successful identification and
authentication of the wireless or
administrator user
(FIA_USB.1(1) and
FIA_USB.1(2)).
Security Management FMT_MOF.1(1) The TOE limits the
management of cryptographic,
FMT_MOF.1(2)
audit, and authentication
FMT_MOF.1(3) security functions behavior to
FMT_MSA.2 administrators (FMT_MOF.1(1),
FMT_MOF.1(2) and
FMT_MTD.1(1) FMT_MOF.1(3)) and ensures
FMT_MTD.1(2) that only secure values are
accepted for security attributes
FMT_SMF.1(1) (FMT_MSA.2).
FMT_SMF.1(2) The TOE limits the
FMT_SMF.1(3) management of audit pre-
selection data and
FMT_SMR.1(1) authentication credentials to
administrators (FMT_MTD.1(1)
and FMT_MTD.1(2)).
The TOE is capable of
performing the management of
the network packets encryption
status, security audit, and
cryptographic key data
(FMT_SMF.1(1),
FMT_SMF.1(2) and
FMT_SMF.1(3)).
The TOE maintains
administrator and wireless user
roles and is able to associate
Page 81 of 85
users with roles
(FMT_SMR.1(1)).
Protection of the TSF FPT_RVM.1(1) The TOE provides for non-
bypassability of the TOE
FPT_SEP.1(1)
Security Policy
FPT_STM_EXP.1 (FPT_RVM.1(1)) and TSF
FPT_TST_EXP.1 domain separation
(FPT_SEP.1(1)).
FPT_TST_EXP.2
The TOE implements a set of
FIPS 140-2 and critical self-
tests executed during initial
start-up and upon administrator
request, or upon key
generation (FPT_TST_EXP.1
and FPT_TST_EXP.2).
TOE Access FTA_SSL.3 The TOE terminates a local
administrator session or a
FTA_TAB.1
wireless user session after a
configurable user inactivity time
interval (FTA_SSL.3).
The TOE displays a default
banner regarding unauthorized
use of the TOE (FTA_TAB.1).
Trusted Path/Channels FTP_ITC_EXP.1(1) The TOE maintains a trusted
IPSec/IKE channel with the
FTP_TRP.1
servers, which can be initiated
by the TOE or the servers
(FTP_ITC_EXP.1(1)).
The TOE uses an EAP trusted
path for wireless user
authentication. The path can be
initiated by wireless client
devices (FTP_TRP.1).
The minimum strength level for the TOE security functions in this ST is SoF-basic. FIA_UAU.1
includes the following probabilistic/permutational mechanism for which specific SOF metrics are
appropriate: password-based administrator authentication. The administrator passwords must be
eight characters or longer in length and are case sensitive, resulting in 958 possible combinations.
The password-based authentication mechanism also enforces the FIPS 140-2 requirement that for
multiple attempts to use the authentication mechanism during a one-minute period, the probability is
less than one in 100,000 that a random attempt will succeed or a false acceptance will occur. If one
tries one million passwords per second, the exploit time is still more than 100 years, which satisfies
the requirements of SoF-basic.
Page 82 of 85
Mapping of assurance measures to assurance requirements is provided in Table 6-1 Assurance
Measures.
8.10 PP Claims Rationale

The TOE conforms to the US Government Wireless Local Area Network (WLAN) Access System
Protection Profile for Basic Robustness Environments, Version 1.0, April 2006.
The following IT security requirements statements included in this ST contain completed WLANAS
PP operations:
FAU_GEN.1, FCS_CKM_EXP.2, FCS_COP_EXP.2, FDP_RIP.1, FIA_AFL.1, FIA_ATD.1,

FIA_UAU.1, FIA_USB.1, FPT_TST_EXP.1, FTP_ITC_EXP.1, FTP_TRP.1, FAU_SAR.3,
FAU_STG.3, FIA_UAU_EXP.5, FIA_UID.1
Except as noted earlier in this section, this ST does not contain any security objectives or TOE
security functional requirements that are additional to the security objectives and the IT security
requirements of WLANAS PP. Additional SFRs for the TOE IT environment have been defined to
provide a more detailed description of the TOE environment - this does not impact the conformance
of this ST to the PP.
The PP includes the requirement FMT_MTD.1(3), which specifies that the TOE users can only
change their own authentication credentials. Since the TOE and the wireless authentication
protocols implemented by the TOE do not allow non-administrator users to change their
authentication credentials, the requirement FMT_MTD.1(3) would need to be refined to specify
“administrators” instead of “TOE Users”. Such a refined requirement would then be a duplicate of
FMT_MTD.1(2), which is already included in the ST. Therefore, both the requirements
FMT_MTD.1(2) and FMT_MTD.1(3) of the PP are covered by the requirement FMT_MTD.1(2) of
the ST.
Page 83 of 85
9 Appendix
Table 9-1 Abbreviations and Acronyms
AES Advanced Encryption Standard

CC Common Criteria
CBC Cipher Block Chaining
CCM Counter with CBC-MAC
EAL Evaluation Assurance Level
EAP Extensible Authentication Protocol
EAP-TLS EAP-Transport Layer Security Protocol
EAP-TTLS EAP-Tunneled Transport Layer Security Protocol
FIPS 140-2 Federal Information Processing Standard Publication 140-2
IKE Internet Key Exchange Protocol
IP Internet Protocol
IPSec IP Security Protocol
IT Information Technology
LAN Local Area Network
NTP Network Time Protocol
MAC Media Access Control
PEAP Protected Extensible Authentication Protocol
PP Protection Profile
SOF Strength of Function
SF Security Function
SFP Security Function Policy
SSH Secure Shell Protocol
ST Security Target
TOE Target of Evaluation
TLS Transport Layer Security Protocol
Triple DES Triple Data Encryption Standard
TSC TSF Scope of Control
TSF TOE Security Functions
TSP TOE Security Policy
WLAN Wireless Local Area Network
WLANAS US Government Wireless Local Area Network (WLAN)
PP Access System Protection Profile for Basic Robustness
Environments, Version 1.0, April 2006.
Table 9-2 References
[1] Common Criteria for Information Technology Security Evaluation, Part 1, Version 2.3, August 2005,
CCMB-2005-08-001
CCMB-2005-08-002
CCMB-2005-08-003
[4] Common Methodology for Information Technology Security Evaluation, Version 2.3, August 2005, CCMB-
2005-08-004
[5] US Government Wireless Local Area Network (WLAN) Access System Protection Profile For Basic
Robustness Environments, Version 1.0, April 2006
Page 84 of 85
[6] FIPS PUB 140-2, Security Requirements for Cryptographic Modules, May 2001
[7] Motorola Wireless Switch Configuration Management Plan and Procedures
[8] Motorola Wireless Switch Delivery and Operation Plan and Procedures
[9] Motorola Wireless Switch Installation Guide
[10] Motorola Wireless Switch Functional Specification
[11] Motorola Wireless Switch High-Level Design Specification
[12] Motorola Wireless Switch Low-Level Design Specification
[13] Motorola Wireless Switch Informal Correspondence Demonstration
[14] Motorola Wireless Switch Security Policy Model
[15] Motorola Wireless Switch CLI Reference Guide
[16] Motorola Wireless Switch Life Cycle Management Plan and Procedures
[17] Motorola Wireless Switch Test Coverage Analysis
[18] Motorola Wireless Switch Testing Plan and Procedures
[19] Motorola Wireless Switch Misuse Analysis
[20] Motorola Wireless Switch Strength of Function Analysis
[21] Motorola Wireless Switch Vulnerability Analysis
Page 85 of 85

Motorola ST v1.5

Uploaded by

Copyright:

Available Formats

Motorola ST v1.5

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Motorola ST v1.5

Uploaded by

Copyright:

Available Formats

Motorola WS5100 Wireless Switch and RFS7000 RF Switch

1 Introduction to the Security Target ....................................................................... 6

Table 3-1 TOE Assumptions ...............................................................................................................................................12

Revision Date Comment

1 Introduction to the Security Target

1.1 Security Target Identification

This Security Target describes two TOEs:

Motorola WS5100 Wireless Switch

Motorola RFS7000 RF Switch

1.2 Security Target Overview

1.3 Common Criteria Conformance

Figure 1. Motorola WS5100 Wireless Switch

Motorola RFS7000 RF Switch is a rack-mounted hardware device with 1U chassis. It supports up to

Figure 2. Motorola RFS7000 RF Switch

In the following, both devices are referred to as “the TOE”.

Figure 3. Typical TOE deployment diagram

TOE Audit Auth Time

2.2 TOE Hardware

2.3 Scope of Evaluation

3 TOE Security Environment

3.1 Secure Usage Assumptions

Table 3-1 TOE Assumptions

3.2 Threats to Security

Table 3-2 Threats

Name Threat Definition

T.POOR_IMPLEMENTATION Unintentional errors in implementation of the TOE design may

T.RESIDUAL_DATA A user or process may gain unauthorized access to data

T.UNATTENDED_ SESSION A user may gain unauthorized access to an unattended

3.3 Organizational Security Policies

Table 3-3 Organizational Security Policies

Policy Name Policy Definition

P.ENCRYPTED_CHANNEL The TOE shall provide the capability to encrypt/decrypt

4.1 Security Objectives for the TOE

Table 4-1 Security Objectives for TOE

Name TOE Security Objective

O.DISPLAY_BANNER The TOE will display an advisory warning prior to

O.MANAGE The TOE will provide functions and facilities necessary to

O.TIME_STAMPS The TOE shall obtain reliable time stamps.

O.DOCUMENTED_ DESIGN The design of the TOE is adequately and accurately

4.2 Security Objectives for the Environment

Table 4-2 Security Objectives for the IT and Non IT Environment

Name Security Objective

OE.AUDIT_REVIEW The IT Environment will provide the capability to selectively view

OE.PROTECT_MGMT_COMMS The environment shall protect the transport of audit records to

OE.RESIDUAL_INFORMATION The TOE IT environment will ensure that any information

OE.TOE_NO_BYPASS Wireless clients are configured so that information cannot flow

5.1 Strength of Function Claims

The strength of function claims in this ST match those of WLANAS PP.

5.2 TOE Security Functional Requirements

Table 5-1 Functional Components

Component Component Name Dependencies

5.2.1 Security Audit

5.2.1.1 FAU_GEN.1(1) Audit data generation

Table 5-2 TOE Auditable Events

Requirement Auditable Events Additional Audit Record

FCS_CKM.4 Destruction of a cryptographic key The identity of the

FIA_ATD.1(1) None None

FMT_MOF.1(2) Start or Stop of audit record generation None