Extreme Networks, Inc. NetIron Family
Devices with Multi-Service IronWare
R06.3.00aa (NDcPP21) Security Target
Version 0.4
September 9, 2019
Prepared for:
Extreme Networks, Inc.
6480 Via Del Oro, San Jose, CA 95119
Prepared By:
www.gossamersec.com
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 2 of 30
1. SECURITY TARGET INTRODUCTION........................................................................................................3
1.1 SECURITY TARGET REFERENCE......................................................................................................................3
1.2 TOE REFERENCE............................................................................................................................................3
1.3 TOE OVERVIEW .............................................................................................................................................4
1.4 TOE DESCRIPTION .........................................................................................................................................4
1.4.1 TOE Architecture...................................................................................................................................4
1.4.2 TOE Documentation ..............................................................................................................................6
2. CONFORMANCE CLAIMS..............................................................................................................................7
2.1 CONFORMANCE RATIONALE...........................................................................................................................7
3. SECURITY OBJECTIVES ................................................................................................................................8
3.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .....................................................................8
4. EXTENDED COMPONENTS DEFINITION ..................................................................................................9
5. SECURITY REQUIREMENTS.......................................................................................................................10
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................10
5.1.1 Security audit (FAU)............................................................................................................................11
5.1.2 Cryptographic support (FCS)..............................................................................................................13
5.1.3 Identification and authentication (FIA) ...............................................................................................16
5.1.4 Security management (FMT) ...............................................................................................................17
5.1.5 Protection of the TSF (FPT) ................................................................................................................18
5.1.6 TOE access (FTA)................................................................................................................................19
5.1.7 Trusted path/channels (FTP) ...............................................................................................................19
5.2 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................20
5.2.1 Development (ADV).............................................................................................................................20
5.2.2 Guidance documents (AGD)................................................................................................................20
5.2.3 Life-cycle support (ALC) .....................................................................................................................21
5.2.4 Tests (ATE) ..........................................................................................................................................22
5.2.5 Vulnerability assessment (AVA)...........................................................................................................22
6. TOE SUMMARY SPECIFICATION..............................................................................................................23
6.1 SECURITY AUDIT ..........................................................................................................................................23
6.2 CRYPTOGRAPHIC SUPPORT ...........................................................................................................................23
6.3 IDENTIFICATION AND AUTHENTICATION.......................................................................................................25
6.4 SECURITY MANAGEMENT .............................................................................................................................27
6.5 PROTECTION OF THE TSF .............................................................................................................................28
6.6 TOE ACCESS.................................................................................................................................................28
6.7 TRUSTED PATH/CHANNELS ...........................................................................................................................29
LIST OF TABLES
Table 5-1 TOE Security Functional Components........................................................................................................11
Table 5-2 Auditable Events .........................................................................................................................................13
Table 5-3 Assurance Components............................................................................................................................20
Table 6-1 CAVP Certificates.......................................................................................................................................24
Table 6-2 Cryptographic Keys and CSPs ....................................................................................................................25
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 3 of 30
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. The TOE is NetIron Family Devices with Multi-Service IronWare
R06.3.00aa provided by Extreme Networks, Inc. The TOE is being evaluated as a network device
The Security Target contains the following additional sections:
 Conformance Claims (Section 2)
 Security Objectives (Section 3)
 Extended Components Definition (Section 4)
 Security Requirements (Section 5)
 TOE Summary Specification (Section 6)
Conventions
The following conventions have been applied in this document:
 Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST,
iteration is indicated by a parenthetical number placed at the end of the component. For example
FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the FDP_ACC.1
requirement.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection
would be identified in italics and with embedded bold brackets (e.g., [[selected-assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and
strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
 Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.1 Security Target Reference
ST Title – Extreme Networks, Inc. NetIron Family Devices with Multi-Service IronWare R06.3.00aa (NDcPP21)
Security Target
ST Version – Version 0.4
ST Date – September 9, 2019
1.2 TOE Reference
TOE Identification – Extreme Networks, Inc. NetIron Family Devices with Multi-Service IronWare R06.3.00aa
including the following series and models:
 Extreme NetIron MLXe Series Hardware Platforms
o BR-MLXE-4-AC,BR-MLXE-8-AC,BR-MLXE-16-AC with management card BR-MLX-MR2-X
o BR-MLXE-32-AC with management card BR-MLX-MR2-32-X
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 4 of 30
 Extreme NetIron CER 2000 Series Hardware Platforms
o BR-CER-2024C-4X-RT
o BR-CER-2024F-4X-RT.
TOE Developer – Extreme Networks, Inc.
Evaluation Sponsor – Extreme Networks, Inc.
1.3 TOE Overview
The Target of Evaluation (TOE) is Extreme Networks, Inc. NetIron Family Devices with Multi-Service IronWare
R06.3.00aa.
The TOE is composed of a hardware appliance with embedded software installed on a management processor. The
embedded software is a version of Extreme’s proprietary Multi-Service IronWare software. The software controls the
switching and routing network frames and packets among the connections available on the hardware appliances.
All TOE appliances are configured at the factory with default parameters to allow immediate use of the system’s basic
features through its Command Line Interface (CLI). However, the product should be configured in accordance with
the evaluated configuration prior to being placed into operation. The CLI is a text based interface which is accessible
from a directly connected terminal or via a remote terminal using SSH. The remote management interface is protected
using encryption provided by the SSH protocol.
The hardware platforms that support the TOE have a number of common hardware characteristics:
 Central processor that supports all system operations, i.e. PowerPC etc.
 Dynamic memory, used by the central processor for all system operations
 Non-volatile flash memory, used to store the operating system image, startup configuration and other relevant
files.
 Multiple physical network interfaces either fixed in configuration or removable as in a chassis based product.
1.4 TOE Description
The Target of Evaluation (TOE) is Extreme Networks, Inc. NetIron Family Devices with Multi-Service IronWare
R06.3.00aa including the following series and models:
 Extreme NetIron MLXe Series Hardware Platforms
o BR-MLXE-4-AC,BR-MLXE-8-AC,BR-MLXE-16-AC with management card BR-MLX-MR2-X
o BR-MLXE-32-AC with management card BR-MLX-MR2-32-X
 Extreme NetIron CER 2000 Series Hardware Platforms
o BR-CER-2024C-4X-RT
o BR-CER-2024F-4X-RT
While there are different models in the TOE, they differ primarily in physical form factor, number and types of
connections and slots, and relative performance. There are some functional differences among the families, but they
each provide the same security characteristics as claimed in this security target.
The different series have differing CPUs as described below
 The MLX Series uses a Freescale MPC 7448, 1666 MHz CPU for the MR2 management models and
 The CER 2000 Series utilize a Freescale MPC8544, PowerQUICCtm
800 MHz CPU
1.4.1 TOE Architecture
The basic architecture of each TOE appliance begins with a hardware appliance with physical network connections.
Within the hardware appliance, the Extreme IronWare OS is designed to control and enable access to the available
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 5 of 30
hardware functions (e.g., program execution, device access, facilitate basic routing functions). IronWare OS enforces
applicable security policies on network information flowing through the hardware appliance.
The basic start-up operation of the TOE is as follows:
1. At system startup the operating system is transferred from flash memory to dynamic memory using a built-
in hardware bootstrap.
2. The operating system reads the configuration parameters from the configuration file in non-volatile memory
and then builds the necessary data structures in dynamic memory and begins operation.
During normal operation, IP packets are sent to the management IP address or through the appliance over one or more
of its physical network interfaces, which processes them according to the system’s configuration and state information
dynamically maintained by the appliance. This processing typically results in the frames or packets being forwarded
out of the device over another interface. The TOE will process other packets destined for itself (control path packets)
based on the requirements of the given protocol (i.e., SSH).
1.4.1.1 Physical Boundaries
Each TOE appliance runs a version of the Extreme’s software and has physical network connections to its environment
to facilitate routing and switching of network traffic. The TOE appliance can also be the destination of network traffic,
where it provides interfaces for its own management.
The TOE may be accessed and managed through a PC or terminal in the environment which can be remote from or
directly connected to the TOE.
The TOE can be configured to forward its audit records to an external syslog server in the network environment. This
is generally advisable given the limited audit log storage space on the evaluated appliances.
NetIron utilizes TLS protected TACACS+ and RADIUS authentication.
1.4.1.2 Logical Boundaries
This section summarizes the security functions provided by Extreme Networks, Inc. NetIron Family Devices with
Multi-Service IronWare R06.3.00aa:
 Security audit
 Cryptographic support
 Identification and authentication
 Security management
 Protection of the TSF
 TOE access
 Trusted path/channels
1.4.1.2.1 Security audit
The TOE is designed to be able to generate logs for a wide range of security relevant events. The TOE can be
configured to store the logs locally so they can be accessed by an administrator and also to send the logs to a designated
log server using TLS to protect the logs while in transit on the network.
1.4.1.2.2 Cryptographic support
The TOE has CAVP-tested algorithms that provide key management, random bit generation, encryption/decryption,
digital signature and secure hashing and key-hashing features in support of higher level cryptographic protocols
including SSH and TLS.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 6 of 30
1.4.1.2.3 Identification and authentication
The TOE requires users to be identified and authenticated before they can use functions mediated by the TOE, with
the exception of passing network traffic in accordance with its configured switching/routing rules. It provides the
ability to both assign attributes (user names, passwords and privilege levels) and to authenticate users against these
attributes. The TOE utilizes x509.3 certificates to authenticate TLS services providing service to the TOE, and
performs certificate status verification using OCSP protocol.
1.4.1.2.4 Security management
The TOE provides Command Line Interface (CLI) commands to access the wide range of security management
functions to manage its security policies. All administrative activity and functions including security management
commands are limited to authorized users (i.e., administrators) only after they have provided acceptable user
identification and authentication data to the TOE. The security management functions are controlled through the use
of privileges associated with roles that can be assigned to TOE users. Among the available privileges, only the Super
User can actually manage the security policies provided by the TOE and the TOE offers a complete set of functions
to facilitate effective management since the Super User allows for complete read-and-write access to the system.
1.4.1.2.5 Protection of the TSF
The TOE implements a number of features design to protect itself to ensure the reliability and integrity of its security
features. It protects particularly sensitive data such as stored passwords and cryptographic keys so that they are not
accessible even by an administrator. It also provides its own timing mechanism to ensure that reliable time information
is available (e.g., for log accountability).
The TOE includes functions to perform self-tests so that it might detect when it is failing. It also includes mechanisms
(i.e., verification of the digital signature of each new image) so that the TOE itself can be updated while ensuring that
the updates will not introduce malicious or other unexpected changes in the TOE.
1.4.1.2.6 TOE access
The TOE can be configured to display a message of the day banner when an administrator establishes an interactive
session and subsequently will enforce an administrator-defined inactivity timeout value after which the inactive
session (local or remote) will be terminated.
1.4.1.2.7 Trusted path/channels
The TOE protects interactive communication with administrators using SSHv2 for CLI access. In each case, both
integrity and disclosure protection is ensured. If the negotiation of an encrypted session fails or if the user does not
have authorization for remote administration, the attempted connection will not be established.
The TOE protects communication with a log server and authentication server (TACACS+ and RADIUS) using TLS
connections to prevent unintended disclosure or modification.
1.4.2 TOE Documentation
Extreme Networks offers documentation that describes the use and administration of the applicable security features
of the TOE. The following document was examined as part of the evaluation.
 Configuration Guide, NetIron Common Criteria, Supporting Network OS 06.3.00aa, September 2019.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 7 of 30
2. Conformance Claims
This TOE is conformant to the following CC specifications:
 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 5, April 2017.
 Part 2 Extended
 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1, Revision 5, April 2017.
 Part 3 Conformant
 Package Claims:
 collaborative Protection Profile for Network Devices, Version 2.1, 11 March 2019 (NDcPP21)
with the following technical decisions:
 TD0425
 TD0424
 TD0423
 TD0412
 TD0410
 TD0409
 TD0408
 TD0407
 TD0402
 TD0401
 TD0400
 TD0399
 TD0398
 TD0397
 TD0396
 TD0395
2.1 Conformance Rationale
The ST conforms to the NDcPP21. As explained previously, the security problem definition, security objectives, and
security requirements have been drawn from the PP.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 8 of 30
3. Security Objectives
The Security Problem Definition may be found in the NDcPP21 and this section reproduces only the corresponding
Security Objectives for operational environment for reader convenience. The NDcPP21 offers additional information
about the identified security objectives, but that has not been reproduced here and the NDcPP21 should be consulted
if there is interest in that material.
In general, the NDcPP21 has defined Security Objectives appropriate for network devices and as such are applicable
to the NetIron Family Devices with Multi-Service IronWare R06.3.00aaTOE.
3.1 Security Objectives for the Operational Environment
OE.ADMIN_CREDENTIALS_SECURE The administrator's credentials (private key) used to access the TOE must
be protected on any other platform on which they reside.
OE.COMPONENTS_RUNNING (applies to distributed TOEs only) For distributed TOEs the Security
Administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an
undetected attack on (or failure of) one or more TOE components. The Security Administrator also ensures that it is
checked as appropriate for every TOE component that the audit functionality is running properly.
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user
applications) available on the TOE, other than those services necessary for the operation, administration and support
of the TOE.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It
is assumed that protection of this traffic will be covered by other security and assurance measures in the operational
environment.
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by
the environment.
OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible
for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking
equipment when the equipment is discarded or removed from its operational environment.
OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all guidance documentation in a trusted
manner. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are assumed to
monitor the revocation status of all certificates in the TOE's trust store and to remove any certificate from the TOE’s
trust store in case such certificate can no longer be trusted.
OE.UPDATES The TOE firmware and software is updated by an administrator on a regular basis in response to the
release of product updates due to known vulnerabilities.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 9 of 30
4. Extended Components Definition
All of the extended requirements in this ST have been drawn from the NDcPP21. The NDcPP21 defines the following
extended requirements and since they are not redefined in this ST the NDcPP21 should be consulted for more
information in regard to those CC extensions.
Extended SFRs:
 NDcPP21:FAU_STG_EXT.1: Protected Audit Event Storage
 NDcPP21:FCS_RBG_EXT.1: Random Bit Generation
 NDcPP21:FCS_SSHS_EXT.1: SSH Server Protocol
 NDcPP21:FCS_TLSC_EXT.1: TLS Client Protocol
 NDcPP21:FIA_PMG_EXT.1: Password Management
 NDcPP21:FIA_UAU_EXT.2: Password-based Authentication Mechanism
 NDcPP21:FIA_UIA_EXT.1: User Identification and Authentication
 NDcPP21:FIA_X509_EXT.1/Rev: X.509 Certificate Validation
 NDcPP21:FIA_X509_EXT.2: X.509 Certificate Authentication
 NDcPP21:FPT_APW_EXT.1: Protection of Administrator Passwords
 NDcPP21:FPT_SKP_EXT.1: Protection of TSF Data (for reading of all pre-shared, symmetric and private keys)
 NDcPP21:FPT_STM_EXT.1: Reliable Time Stamps
 NDcPP21:FPT_TST_EXT.1: TSF testing
 NDcPP21:FPT_TUD_EXT.1: Trusted update
 NDcPP21:FTA_SSL_EXT.1: TSF-initiated Session Locking
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 10 of 30
5. Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that
serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort.
The SFRs have all been drawn from the NDcPP21. The refinements and operations already performed in the
NDcPP21are not identified (e.g., highlighted) here, rather the requirements have been copied from the NDcPP21 and
any residual operations have been completed herein. Of particular note, the NDcPP21 made a number of refinements
and completed some of the SFR operations defined in the Common Criteria (CC) and that PP should be consulted to
identify those changes if necessary.
The SARs are also drawn from the NDcPP21 which includes all the SARs for EAL 1. However, the SARs are
effectively refined since requirement-specific 'Assurance Activities' are defined in the NDcPP21 that serve to ensure
corresponding evaluations will yield more practical and consistent assurance than the EAL 1 assurance requirements
alone. The NDcPP21 should be consulted for the assurance activity definitions.
5.1 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by NetIron Family Devices with Multi-Service IronWare
R06.3.00aa TOE.
Requirement Class Requirement Component
FAU: Security audit NDcPP21:FAU_GEN.1: Audit Data Generation
NDcPP21:FAU_GEN.2: User identity association
NDcPP21:FAU_STG_EXT.1: Protected Audit Event Storage
FCS: Cryptographic support NDcPP21:FCS_CKM.1: Cryptographic Key Generation
NDcPP21:FCS_CKM.2: Cryptographic Key Establishment
NDcPP21:FCS_CKM.4: Cryptographic Key Destruction
NDcPP21:FCS_COP.1/DataEncryption: Cryptographic Operation
(AES Data Encryption/Decryption)
NDcPP21:FCS_COP.1/Hash: Cryptographic Operation (Hash
Algorithm)
NDcPP21:FCS_COP.1/KeyedHash: Cryptographic Operation (Keyed
Hash Algorithm)
NDcPP21:FCS_COP.1/SigGen: Cryptographic Operation (Signature
Generation and Verification)
NDcPP21:FCS_RBG_EXT.1: Random Bit Generation
NDcPP21:FCS_SSHS_EXT.1: SSH Server Protocol
NDcPP21:FCS_TLSC_EXT.1: TLS Client Protocol
FIA: Identification and
authentication
NDcPP21:FIA_AFL.1: Authentication Failure Management
NDcPP21:FIA_PMG_EXT.1: Password Management
NDcPP21:FIA_UAU.7: Protected Authentication Feedback
NDcPP21:FIA_UAU_EXT.2: Password-based Authentication
Mechanism
NDcPP21:FIA_UIA_EXT.1: User Identification and Authentication
NDcPP21:FIA_X509_EXT.1/Rev: X.509 Certificate Validation
NDcPP21:FIA_X509_EXT.2: X.509 Certificate Authentication
FMT: Security management NDcPP21:FMT_MOF.1/ManualUpdate: Management of security
functions behaviour
NDcPP21:FMT_MTD.1/CoreData: Management of TSF Data
NDcPP21:FMT_MTD.1/CryptoKeys: Management of TSF data
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 11 of 30
NDcPP21:FMT_SMF.1: Specification of Management Functions
NDcPP21:FMT_SMR.2: Restrictions on Security Roles
FPT: Protection of the TSF NDcPP21:FPT_APW_EXT.1: Protection of Administrator Passwords
NDcPP21:FPT_SKP_EXT.1: Protection of TSF Data (for reading of
all pre-shared, symmetric and private keys)
NDcPP21:FPT_STM_EXT.1: Reliable Time Stamps
NDcPP21:FPT_TST_EXT.1: TSF testing
NDcPP21:FPT_TUD_EXT.1: Trusted update
FTA: TOE access NDcPP21:FTA_SSL.3: TSF-initiated Termination
NDcPP21:FTA_SSL.4: User-initiated Termination
NDcPP21:FTA_SSL_EXT.1: TSF-initiated Session Locking
NDcPP21:FTA_TAB.1: Default TOE Access Banners
FTP: Trusted path/channels NDcPP21:FTP_ITC.1: Inter-TSF trusted channel
NDcPP21:FTP_TRP.1/Admin: Trusted Path
Table 5-1 TOE Security Functional Components
5.1.1 Security audit (FAU)
5.1.1.1 Audit Data Generation (NDcPP21:FAU_GEN.1)
NDcPP21:FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
- Administrative login and logout (name of user account shall be logged if individual
user accounts are required for administrators).
- Changes to TSF data related to configuration changes (in addition to the information
that a change occurred it shall be logged what has been changed).
- Generating/import of, changing, or deleting of cryptographic keys (in addition to the
action itself a unique key name or key reference shall be logged).
- Resetting passwords (name of related user account shall be logged).
- [no other actions];
d) Specifically defined auditable events listed in Table 5-2.
Requirement Auditable Events Additional Content
NDcPP21:FAU_GEN.1
NDcPP21:FAU_GEN.2
NDcPP21:FAU_STG_EXT.1
NDcPP21:FCS_CKM.1
NDcPP21:FCS_CKM.2
NDcPP21:FCS_CKM.4
NDcPP21:FCS_COP.1/DataEncryption
NDcPP21:FCS_COP.1/Hash
NDcPP21:FCS_COP.1/KeyedHash
NDcPP21:FCS_COP.1/SigGen
NDcPP21:FCS_RBG_EXT.1
NDcPP21:FCS_SSHS_EXT.1 Failure to establish an SSH
session.
Reason for failure.
NDcPP21:FCS_TLSC_EXT.1 Failure to establish a TLS
Session.
Reason for failure.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 12 of 30
NDcPP21:FIA_AFL.1 Unsuccessful login attempt limit
is met or exceeded.
Origin of the attempt (e.g., IP
address).
NDcPP21:FIA_PMG_EXT.1
NDcPP21:FIA_UAU.7
NDcPP21:FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
NDcPP21:FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
NDcPP21:FIA_X509_EXT.1/Rev Unsuccessful attempt to validate
a certificate. Any addition,
replacement or removal of trust
anchors in the TOE's trust store
Reason for failure of certificate
validation Identification of
certificates added, replaced or
removed as trust anchor in the
TOE's trust store
NDcPP21:FIA_X509_EXT.2
NDcPP21:FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update.
NDcPP21:FMT_MTD.1/CoreData
NDcPP21:FMT_MTD.1/CryptoKeys Management of cryptographic
keys.
NDcPP21:FMT_SMF.1 All management activities of TSF
data.
NDcPP21:FMT_SMR.2
NDcPP21:FPT_APW_EXT.1
NDcPP21:FPT_SKP_EXT.1
NDcPP21:FPT_STM_EXT.1 Discontinuous changes to time -
either Administrator actuated or
changed via an automated
process. (Note that no continuous
changes to time need to be
logged. See also application note
on FPT_STM_EXT.1)
For discontinuous changes to
time: The old and new values
for the time. Origin of the
attempt to change time for
success and failure (e.g., IP
address).
NDcPP21:FPT_TST_EXT.1
NDcPP21:FPT_TUD_EXT.1 Initiation of update; result of the
update attempt (success or
failure).
NDcPP21:FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
NDcPP21:FTA_SSL.4 The termination of an interactive
session.
NDcPP21:FTA_SSL_EXT.1 (if 'lock the session' is selected)
Any attempts at unlocking of an
interactive session. (if 'terminate
the session' is selected) The
termination of a local session by
the session locking mechanism.
NDcPP21:FTA_TAB.1
NDcPP21:FTP_ITC.1 Initiation of the trusted channel.
Termination of the trusted
channel. Failure of the trusted
channel functions.
Identification of the initiator
and target of failed trusted
channels establishment attempt.
NDcPP21:FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted path.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 13 of 30
Failure of the trusted path
functions.
Table 5-2 Auditable Events
NDcPP21:FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional components included in the
cPP/ST, information specified in column three of Table 5-2.
5.1.1.2 User identity association (NDcPP21:FAU_GEN.2)
NDcPP21: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.1.1.3 Protected Audit Event Storage (NDcPP21:FAU_STG_EXT.1)
NDcPP21:FAU_STG_EXT.1.1
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted
channel according to FTP_ITC.1.
NDcPP21:FAU_STG_EXT.1.2
The TSF shall be able to store generated audit data on the TOE itself.
[TOE shall consist of a single standalone component that stores audit data locally,]
NDcPP21:FAU_STG_EXT.1.3
The TSF shall [overwrite previous audit records according to the following rule: [oldest audit
records are overwritten first]] when the local storage space for audit data is full.
5.1.2 Cryptographic support (FCS)
5.1.2.1 Cryptographic Key Generation (NDcPP21:FCS_CKM.1)
NDcPP21:FCS_CKM.1.1
The TSF shall generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm: [
- RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.3,
- FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.1,
- FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC 3526,
Section 3].
5.1.2.2 Cryptographic Key Establishment (NDcPP21:FCS_CKM.2)
NDcPP21:FCS_CKM.2.1
The TSF shall perform cryptographic key establishment in accordance with a specified
cryptographic key establishment method: [
- RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as
specified in Section 7.2 of RFC 8017 “Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications” Version 2.1 (TD0402 applied),
- Finite field-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, 'Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography',
- Key establishment scheme using Diffie-Hellman group 14 that meets the following:
RFC 3526, Section 3].
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 14 of 30
5.1.2.3 Cryptographic Key Destruction (NDcPP21:FCS_CKM.4)
NDcPP21:FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key
destruction method
- For plaintext keys in volatile storage, the destruction shall be executed by a [single
overwrite consisting of [zeroes]];
- For plaintext keys in non-volatile storage, the destruction shall be executed by the
invocation of an interface provided by a part of the TSF that [ instructs a part of the TSF
to destroy the abstraction that represents the key]
that meets the following: No Standard.
5.1.2.4 Cryptographic Operation (AES Data Encryption/Decryption)
(NDcPP21:FCS_COP.1/DataEncryption)
NDcPP21:FCS_COP.1.1/DataEncryption
The TSF shall perform encryption/decryption in accordance with a specified cryptographic
algorithm AES used in [CBC] mode and cryptographic key sizes [128 bits, 256 bits] that meet the
following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116].
5.1.2.5 Cryptographic Operation (Hash Algorithm) (NDcPP21:FCS_COP.1/Hash)
NDcPP21:FCS_COP.1.1/Hash
The TSF shall perform cryptographic hashing services in accordance with a specified
cryptographic algorithm [SHA-1, SHA-256] and message digest sizes [160, 256] that meet the
following: ISO/IEC 10118-3:2004.
5.1.2.6 Cryptographic Operation (Keyed Hash Algorithm) (NDcPP21:FCS_COP.1/KeyedHash)
NDcPP21:FCS_COP.1.1/KeyedHash
The TSF shall perform keyed-hash message authentication in accordance with a specified
cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256,] and cryptographic key sizes [160,
256] and message digest sizes [160, 256] bits that meet the following: ISO/IEC 9797-2:2011,
Section 7 'MAC Algorithm 2'.
5.1.2.7 Cryptographic Operation (Signature Generation and Verification) (NDcPP21:FCS_COP.1/SigGen)
NDcPP21:FCS_COP.1.1/SigGen
The TSF shall perform cryptographic signature services (generation and verification) in
accordance with a specified cryptographic algorithm [
- RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048 bits],
that meet the following: [
- For RSA schemes: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 5.5,
using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5;
ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3].
5.1.2.8 Random Bit Generation (NDcPP21:FCS_RBG_EXT.1)
NDcPP21:FCS_RBG_EXT.1.1
The TSF shall perform all deterministic random bit generation services in accordance with
ISO/IEC 18031:2011 using [CTR_DRBG (AES)].
NDcPP21:FCS_RBG_EXT.1.2
The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy
from [[one] software-based noise source] with a minimum of [256 bits] of entropy at least equal
to the greatest security strength, according to ISO/IEC 18031:2011Table C.1 'Security Strength
Table for Hash Functions', of the keys and hashes that it will generate.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 15 of 30
5.1.2.9 SSH Server Protocol (NDcPP21:FCS_SSHS_EXT.1)
NDcPP21:FCS_SSHS_EXT.1.1
The TSF shall implement the SSH protocol that complies with RFC(s) [4251, 4252, 4253, 4254].
(TD0398 applied)
NDcPP21:FCS_SSHS_EXT.1.2
The TSF shall ensure that the SSH protocol implementation supports the following authentication
methods as described in RFC 4252: public key-based, [password-based].
NDcPP21:FCS_SSHS_EXT.1.3
The TSF shall ensure that, as described in RFC 4253, packets greater than [256K] bytes in an SSH
transport connection are dropped.
NDcPP21:FCS_SSHS_EXT.1.4
The TSF shall ensure that the SSH transport implementation uses the following encryption
algorithms and rejects all other encryption algorithms: [aes128-cbc, aes256-cbc].
NDcPP21:FCS_SSHS_EXT.1.5
The TSF shall ensure that the SSH public-key based authentication implementation uses [ssh-rsa]
as its public key algorithm(s) and rejects all other public key algorithms. (TD0424 applied)
NDcPP21:FCS_SSHS_EXT.1.6
The TSF shall ensure that the SSH transport implementation uses [hmac-sha1] as its data
integrity MAC algorithm(s) and rejects all other MAC algorithm(s).
NDcPP21:FCS_SSHS_EXT.1.7
The TSF shall ensure that [diffie-hellman-group14-sha1] and [no other methods] are the only
allowed key exchange methods used for the SSH protocol.
NDcPP21:FCS_SSHS_EXT.1.8
The TSF shall ensure that within SSH connections the same session keys are used for a threshold
of no longer than one hour, and no more than one gigabyte of transmitted data. After either of the
thresholds are reached a rekey needs to be performed.
5.1.2.10 TLS Client Protocol (NDcPP21:FCS_TLSC_EXT.1)
NDcPP21:FCS_TLSC_EXT.1.1
The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS
and SSL versions. The TLS implementation will support the following ciphersuites: [
TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246].
NDcPP21:FCS_TLSC_EXT.1.2
The TSF shall verify that the presented identifier matches the reference identifier per RFC 6125
section 6.
NDcPP21:FCS_TLSC_EXT.1.3
When establishing a trusted channel, by default the TSF shall not establish a trusted channel if the
server certificate is invalid. The TSF shall also [Not implement any administrator override
mechanism].
NDcPP21:FCS_TLSC_EXT.1.4
The TSF shall [not present the Supported Elliptic Curves Extension] in the Client Hello.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 16 of 30
5.1.3 Identification and authentication (FIA)
5.1.3.1 Authentication Failure Management (NDcPP21:FIA_AFL.1)
NDcPP21:FIA_AFL.1.1
The TSF shall detect when an Administrator configurable positive integer within [1 to 5]
unsuccessful authentication attempts occur related to Administrators attempting to authenticate
remotely using a password. (TD0408 applied)
NDcPP21:FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been met, the TSF shall
[prevent the offending Administrator from successfully establishing remote session using any
authentication method that involves a password until [assignment: action to unlock] is taken by
an Administrator]. (TD0408 applied)
5.1.3.2 Password Management (NDcPP21:FIA_PMG_EXT.1)
NDcPP21:FIA_PMG_EXT.1.1
The TSF shall provide the following password management capabilities for administrative
passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the
following special characters: ['!', '@', '#', '$', '%', '^', '&', '*', '(', ')'];
b) Minimum password length shall be configurable to between [8] and [48] characters.
5.1.3.3 Protected Authentication Feedback (NDcPP21:FIA_UAU.7)
NDcPP21:FIA_UAU.7.1
The TSF shall provide only obscured feedback to the administrative user while the authentication
is in progress at the local console.
5.1.3.4 Password-based Authentication Mechanism (NDcPP21:FIA_UAU_EXT.2)
NDcPP21:FIA_UAU_EXT.2.1
The TSF shall provide a local [password-based, SSH public key-based, [TACACS+ based,
RADIUS-based]] authentication mechanism to perform local administrative user authentication.
(TD0408 applied)
5.1.3.5 User Identification and Authentication (NDcPP21:FIA_UIA_EXT.1)
NDcPP21:FIA_UIA_EXT.1.1
The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the
identification and authentication process:
- Display the warning banner in accordance with FTA_TAB.1;
- [no other actions].
NDcPP21:FIA_UIA_EXT.1.2
The TSF shall require each administrative user to be successfully identified and authenticated
before allowing any other TSF-mediated actions on behalf of that administrative user.
5.1.3.6 X.509 Certificate Validation (NDcPP21:FIA_X509_EXT.1/Rev)
NDcPP21:FIA_X509_EXT.1.1/Rev
The TSF shall validate certificates in accordance with the following rules:
- RFC 5280 certificate validation and certification path validation supporting a minimum
path length of three certificates.
- The certification path must terminate with a trusted CA certificate designated as a trust
anchor.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 17 of 30
- The TSF shall validate a certification path by ensuring that all CA certificates in the
certification path contain the basicConstraints extension with the CA flag set to TRUE.
- The TSF shall validate the revocation status of the certificate using [the Online
Certificate Status Protocol (OCSP) as specified in RFC 6960]
- The TSF shall validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates and executable code integrity verification
shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication
purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication
purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP Signing
purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
NDcPP21:FIA_X509_EXT.1.2/Rev
The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is
present and the CA flag is set to TRUE.
5.1.3.7 X.509 Certificate Authentication (NDcPP21:FIA_X509_EXT.2)
NDcPP21:FIA_X509_EXT.2.1
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
[TLS], and [no additional uses].
NDcPP21:FIA_X509_EXT.2.2
When the TSF cannot establish a connection to determine the validity of a certificate, the TSF
shall [not accept the certificate].
5.1.4 Security management (FMT)
5.1.4.1 Management of security functions behaviour (NDcPP21:FMT_MOF.1/ManualUpdate)
NDcPP21:FMT_MOF.1.1/ManualUpdate
The TSF shall restrict the ability to enable the functions to perform manual update to Security
Administrators.
5.1.4.2 Management of TSF Data (NDcPP21:FMT_MTD.1/CoreData)
NDcPP21:FMT_MTD.1.1/CoreData
The TSF shall restrict the ability to manage the TSF data to Security Administrators.
5.1.4.3 Management of TSF data (NDcPP21:FMT_MTD.1/CryptoKeys)
NDcPP21:FMT_MTD.1.1/CryptoKeys
The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators.
5.1.4.4 Specification of Management Functions (NDcPP21:FMT_SMF.1)
NDcPP21:FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
- Ability to administer the TOE locally and remotely;
- Ability to configure the access banner;
- Ability to configure the session inactivity time before session termination or locking;
- Ability to update the TOE, and to verify the updates using [digital signature] capability prior
to installing those updates;
- Ability to configure the authentication failure parameters for FIA_AFL.1;
- [Ability to configure audit behavior,
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 18 of 30
- Ability to configure the list of TOE-provided services available before an entity is identified
and authenticated, as specified in FIA_UIA_EXT.1,
- Ability to re-enable an Administrator account,
- Ability to manage the cryptographic keys,
- Ability to configure the cryptographic functionality,
- Ability to configure thresholds for SSH rekeying,
- Ability to set the time which is used for time-stamps;].
5.1.4.5 Restrictions on Security Roles (NDcPP21:FMT_SMR.2)
NDcPP21:FMT_SMR.2.1
The TSF shall maintain the roles: - Security Administrator.
NDcPP21:FMT_SMR.2.2
The TSF shall be able to associate users with roles.
NDcPP21:FMT_SMR.2.3
The TSF shall ensure that the conditions
- The Security Administrator role shall be able to administer the TOE locally;
- The Security Administrator role shall be able to administer the TOE remotely are satisfied.
5.1.5 Protection of the TSF (FPT)
5.1.5.1 Protection of Administrator Passwords (NDcPP21:FPT_APW_EXT.1)
NDcPP21:FPT_APW_EXT.1.1
The TSF shall store passwords in non-plaintext form.
NDcPP21:FPT_APW_EXT.1.2
The TSF shall prevent the reading of plaintext passwords.
5.1.5.2 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys)
(NDcPP21:FPT_SKP_EXT.1)
NDcPP21:FPT_SKP_EXT.1.1
The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys.
5.1.5.3 Reliable Time Stamps (NDcPP21:FPT_STM_EXT.1)
NDcPP21:FPT_STM_EXT.1.1
The TSF shall be able to provide reliable time stamps for its own use.
NDcPP21:FPT_STM_EXT.1.2
The TSF shall [allow the Security Administrator to set the time].
5.1.5.4 TSF testing (NDcPP21:FPT_TST_EXT.1)
NDcPP21:FPT_TST_EXT.1.1
The TSF shall run a suite of the following self-tests [during initial start-up (on power on)] to
demonstrate the correct operation of the TSF: [ - Cryptographic Known Answer Test (KAT), -
Continuous Tests for entropy and RNG, - Firmware load test].
5.1.5.5 Trusted update (NDcPP21:FPT_TUD_EXT.1)
NDcPP21:FPT_TUD_EXT.1.1
The TSF shall provide Security Administrators the ability to query the currently executing version
of the TOE firmware/software and [no other TOE firmware/software version].
NDcPP21:FPT_TUD_EXT.1.2
The TSF shall provide Security Administrators the ability to manually initiate updates to TOE
firmware/software and [no other update mechanism].
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 19 of 30
NDcPP21:FPT_TUD_EXT.1.3
The TSF shall provide means to authenticate firmware/software updates to the TOE using a
[digital signature mechanism] prior to installing those updates.
5.1.6 TOE access (FTA)
5.1.6.1 TSF-initiated Termination (NDcPP21:FTA_SSL.3)
NDcPP21:FTA_SSL.3.1
The TSF shall terminate a remote interactive session after a Security Administrator-configurable
time interval of session inactivity.
5.1.6.2 User-initiated Termination (NDcPP21:FTA_SSL.4)
NDcPP21:FTA_SSL.4.1
The TSF shall allow Administrator-initiated termination of the Administrator's own interactive
session.
5.1.6.3 TSF-initiated Session Locking (NDcPP21:FTA_SSL_EXT.1)
NDcPP21:FTA_SSL_EXT.1.1
The TSF shall, for local interactive sessions, [terminate the session] after a Security
Administrator-specified time period of inactivity.
5.1.6.4 Default TOE Access Banners (NDcPP21:FTA_TAB.1)
NDcPP21:FTA_TAB.1.1
Before establishing an administrative user session the TSF shall display a Security Administrator-
specified advisory notice and consent warning message regarding use of the TOE.
5.1.7 Trusted path/channels (FTP)
5.1.7.1 Inter-TSF trusted channel (NDcPP21:FTP_ITC.1)
NDcPP21:FTP_ITC.1.1
The TSF shall be capable of using [TLS] to provide a trusted communication channel between
itself and authorized IT entities supporting the following capabilities: audit server, [authentication
server] that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from disclosure and detection of
modification of the channel data.
NDcPP21:FTP_ITC.1.2
The TSF shall permit the TSF or the authorized IT entities to initiate communication via the
trusted channel.
NDcPP21:FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for [exporting audit events, and
communicating with the authentication Server].
5.1.7.2 Trusted Path (NDcPP21:FTP_TRP.1/Admin)
NDcPP21:FTP_TRP.1.1/Admin
The TSF shall be capable of using [SSH] to provide a communication path between itself and
authorized remote Administrators that is logically distinct from other communication paths and
provides assured identification of its end points and protection of the communicated data from
disclosure and provides detection of modification of the channel data.
NDcPP21:FTP_TRP.1.2/Admin
The TSF shall permit remote Administrators to initiate communication via the trusted path.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 20 of 30
NDcPP21:FTP_TRP.1.3/Admin
The TSF shall require the use of the trusted path for initial Administrator authentication and all
remote administration actions.
5.2 TOE Security Assurance Requirements
The SARs for the TOE are the components as specified in Part 3 of the Common Criteria. Note that the SARs have
effectively been refined with the assurance activities explicitly defined in association with both the SFRs and SARs.
Requirement Class Requirement Component
ADV: Development ADV_FSP.1: Basic Functional Specification
AGD: Guidance documents AGD_OPE.1: Operational User Guidance
AGD_PRE.1: Preparative Procedures
ALC: Life-cycle support ALC_CMC.1: Labelling of the TOE
ALC_CMS.1: TOE CM Coverage
ATE: Tests ATE_IND.1: Independent Testing - Conformance
AVA: Vulnerability assessment AVA_VAN.1: Vulnerability Survey
Table 5-3 Assurance Components
5.2.1 Development (ADV)
5.2.1.1 Basic Functional Specification (ADV_FSP.1)
ADV_FSP.1.1d
The developer shall provide a functional specification.
ADV_FSP.1.2d
The developer shall provide a tracing from the functional specification to the SFRs.
ADV_FSP.1.1c
The functional specification shall describe the purpose and method of use for each SFR-enforcing
and SFR-supporting TSFI.
ADV_FSP.1.2c
The TSF shall support mutual authentication of TLS clients using X.509v3 certificates.
ADV_FSP.1.3c
The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering.
ADV_FSP.1.4c
The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.
ADV_FSP.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADV_FSP.1.2e
The evaluator shall determine that the functional specification is an accurate and complete
instantiation of the SFRs.
5.2.2 Guidance documents (AGD)
5.2.2.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1.1d
The developer shall provide operational user guidance.
AGD_OPE.1.1c
The operational user guidance shall describe, for each user role, the useraccessible functions and
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 21 of 30
privileges that should be controlled in a secure processing environment, including appropriate
warnings.
AGD_OPE.1.2c
The operational user guidance shall describe, for each user role, how to use the available interfaces
provided by the TOE in a secure manner.
AGD_OPE.1.3c
The operational user guidance shall describe, for each user role, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
values as appropriate.
AGD_OPE.1.4c
The operational user guidance shall, for each user role, clearly present each type of security-
relevant event relative to the user-accessible functions that need to be performed, including
changing the security characteristics of entities under the control of the TSF.
AGD_OPE.1.5c
The operational user guidance shall identify all possible modes of operation of the TOE (including
operation following failure or operational error), their consequences, and implications for
maintaining secure operation.
AGD_OPE.1.6c
The operational user guidance shall, for each user role, describe the security measures to be
followed in order to fulfill the security objectives for the operational environment as described in
the ST.
AGD_OPE.1.7c
The operational user guidance shall be clear and reasonable.
AGD_OPE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.2.2 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1.1d
The developer shall provide the TOE, including its preparative procedures.
AGD_PRE.1.1c
The preparative procedures shall describe all the steps necessary for secure acceptance of the
delivered TOE in accordance with the developer's delivery procedures.
AGD_PRE.1.2c
The preparative procedures shall describe all the steps necessary for secure installation of the TOE
and for the secure preparation of the operational environment in accordance with the security
objectives for the operational environment as described in the ST.
AGD_PRE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
AGD_PRE.1.2e
The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared
securely for operation.
5.2.3 Life-cycle support (ALC)
5.2.3.1 Labelling of the TOE (ALC_CMC.1)
ALC_CMC.1.1d
The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.1.1c
The TOE shall be labelled with its unique reference.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 22 of 30
ALC_CMC.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.3.2 TOE CM Coverage (ALC_CMS.1)
ALC_CMS.1.1d
The developer shall provide a configuration list for the TOE.
ALC_CMS.1.1c
The configuration list shall include the following: the TOE itself; and the evaluation evidence
required by the SARs.
ALC_CMS.1.2c
The configuration list shall uniquely identify the configuration items.
ALC_CMS.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.4 Tests (ATE)
5.2.4.1 Independent Testing - Conformance (ATE_IND.1)
ATE_IND.1.1d
The developer shall provide the TOE for testing.
ATE_IND.1.1c
The TOE shall be suitable for testing.
ATE_IND.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ATE_IND.1.2e
The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
5.2.5 Vulnerability assessment (AVA)
5.2.5.1 Vulnerability Survey (AVA_VAN.1)
AVA_VAN.1.1d
The developer shall provide the TOE for testing.
AVA_VAN.1.1c
The TOE shall be suitable for testing.
AVA_VAN.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence..
AVA_VAN.1.2e
The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
in the TOE.
AVA_VAN.1.3e
The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to
determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack
potential.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 23 of 30
6. TOE Summary Specification
This chapter describes the security functions:
 Security audit
 Cryptographic support
 Identification and authentication
 Security management
 Protection of the TSF
 TOE access
 Trusted path/channels
6.1 Security audit
The TOE is a standalone (non-distributed) device that is designed to produce syslog conformant messages in a number
of circumstances including warnings about the device itself (such as temperature, power failures, etc.) as well as
security relevant events (the success and failure login of the user, regardless of the authentication mechanism;
changing a user’s password; and adding and deleting user accounts). In each case the audit record includes the time
and date, identification of the responsible subject (e.g., by network address or user ID), the type of event, the outcome
of the event, and other information depending on the event type.
The audit records are stored in a log (internal to the TOE appliance) that is protected so that only an authorized TOE
User can read the audit log. The TOE provides tools accessible via the CLI to read the audit log. The protection
results from the fact that the logs can be accessed only after a user logs in (see section 6.4 below).
By default this log stores 500 entries after which the audit entries will be overwritten, oldest first. The administrator
(with Super User privilege) can (and should) choose to configure one or more external syslog servers where the TOE
will simultaneously send a copy of the audit records. The TOE can be configured to use TLS (to protect audit logs
exported to an external server.
The TOE includes a hardware clock that is used to provide reliable time information for the audit records it generates.
The Security audit function satisfies the following security functional requirements:
 NDcPP21:FAU_GEN.1: The TOE can generate audit records for events include starting and stopping the
audit function, administrator commands, and all other events identified in Section 5.1.1.1. Furthermore, each
audit record identifies the date/time, event type, outcome of the event, responsible subject/user, as well as the
additional event-specific content indicated in Section 5.1.1.1. For cryptographic keys, the act of importing
and deleting a key is audited and the associated administrator account that performed the action is recorded.
The only non-ephemeral cryptographic key used by the TOE is an SSH host key. The TOE audits the
generation and clearing of this key and identifies it as the Host Key.
 NDcPP21:FAU_GEN.2: The TOE identifies the responsible user for each event based on the specific
administrator or network entity (identified by IP address) that caused the event.
 NDcPP21:FAU_STG_EXT.1: The TOE can be configured to export audit records to an external SYSLOG
server. This communication is protected with the use of TLS.
6.2 Cryptographic support
The TOE supports a range of cryptographic services provided by Extreme NetIron MP Crypto Library Version 4.0
firmware running on MPC processors in the evaluated TOE models identified in section 1.2. The following
functions have been CAVP tested as shown by
Functions Requirement Cert #
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 24 of 30
Encryption/Decryption
AES CBC (128 and 256 bits) NDcPP21:FCS_COP.1/DataEncryption CAVP C881
Cryptographic hashing
SHA-1, SHA-256, (digest sizes 160,
256)
NDcPP21:FCS_COP.1/Hash CAVP C881
Keyed-hash message authentication
HMAC-SHA-1, HMAC-SHA-256,
(digest sizes 160, 256)
NDcPP21:FCS_COP.1/KeyedHash CAVP C881
Cryptographic signature services
RSA Digital Signature Algorithm
(rDSA) (modulus 2048)
NDcPP21:FCS_COP.1/SigGen CAVP C881
RSA SigGen and
RSA SigVer
Random bit generation
CTR_DRBG with sw based noise
sources with a minimum of 256 bits of
non-determinism
NDcPP21:FCS_RBG_EXT.1 CAVP C881
Key Generation
RSA Key Generation NDcPP21:FCS_CKM.1 CAVP C881
DSA Key Generation NDcPP21:FCS_CKM.1 CAVP C881
Key Establishment
RSA Key Establishment NDcPP21:FCS_CKM.2 Vendor Affirmed
FFC Key Establishment NDcPP21:FCS_CKM.2 CAVP C881
KAS FFC
Table 6-1 CAVP Certificates.
Functions Requirement Cert #
Encryption/Decryption
AES CBC (128 and 256 bits) NDcPP21:FCS_COP.1/DataEncryption CAVP C881
Cryptographic hashing
SHA-1, SHA-256, (digest sizes 160,
256)
NDcPP21:FCS_COP.1/Hash CAVP C881
Keyed-hash message authentication
HMAC-SHA-1, HMAC-SHA-256,
(digest sizes 160, 256)
NDcPP21:FCS_COP.1/KeyedHash CAVP C881
Cryptographic signature services
RSA Digital Signature Algorithm
(rDSA) (modulus 2048)
NDcPP21:FCS_COP.1/SigGen CAVP C881
RSA SigGen and
RSA SigVer
Random bit generation
CTR_DRBG with sw based noise
sources with a minimum of 256 bits of
non-determinism
NDcPP21:FCS_RBG_EXT.1 CAVP C881
Key Generation
RSA Key Generation NDcPP21:FCS_CKM.1 CAVP C881
DSA Key Generation NDcPP21:FCS_CKM.1 CAVP C881
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 25 of 30
Key Establishment
RSA Key Establishment NDcPP21:FCS_CKM.2 Vendor Affirmed
FFC Key Establishment NDcPP21:FCS_CKM.2 CAVP C881
KAS FFC
Table 6-1 CAVP Certificates
The TOE supports the SSHv2 (compliant with RFCs 4251, 4252, 4253, and 4254. No additional options). The TOE
supports SSHv2 with AES (CBC mode) 128 or 256 bit ciphers, in conjunction with HMAC-SHA-1 for message
integrity. The TOE supports the following public key methods – ssh-rsa. The TOE offers the following key exchange
methods - diffie-hellman-group14-sha1.
The TOE allows users to perform SSHv2 authentication using password based authentication and allows users to
upload a public key for SSHv2 public key client authentication. The TOE’s SSHv2 implementation limits SSH
packets to a size of 256K bytes. Whenever the timeout period or authentication retry limit is reached, the TOE closes
the applicable TCP connection and releases the SSH session resources. As SSH packets are being received, the TOE
uses a buffer to build all packet information. Once complete, the packet is checked to ensure it can be appropriately
decrypted. However, if it is not complete when the buffer becomes full (256K bytes) the packet will be dropped and
the connection terminated. There is a TOE initiated rekey before 1 hour or before 1GB whichever comes first. These
are the default rekey values and they can be modified only by the administrator.
The TOE supports protected communication channels using and TLS v1.1 (RFC4346), and TLS v1.2 (RFC 5246)
secure communication protocols. The TOE supports use of the following ciphersuites:
 TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
 TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
 TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
 TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246,
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246.
The TOE supports the following secret keys, private keys and CSPs:
Key or CSP: Zeroized upon: Stored in: Zeroized by:
SSH host private key Command Flash Overwriting once with zeros
SSH host public key Command Flash Overwriting once with zeros
SSH client public key Command Flash Overwriting once with zeros
SSH session key End of session RAM Overwriting once with zeros
TLS pre-master secret Handshake done RAM Overwriting once with zeros
TLS session key Close of session RAM Overwriting once with zeros
User Password Command Flash Overwriting once with zeros
DRBG Seed Every 100ms RAM Overwritten with new value
Table 6-2 Cryptographic Keys and CSPs
The TOE will establish a trusted channel to an audit server or authentication server only if the server provides a valid
x509v3 certificate that identifies the expected server and which chains to a trusted root.
The Cryptographic support function satisfies the following security functional requirements:
 NDcPP21:FCS_CKM.1: The TOE supports asymmetric key generation using RSA key establishment (key
size 2048) as part of TLS and SSH as described in the section above. The TOE acts as a client for TLS (RSA)
and a server for SSH (RSA, DH-14 key generation). The TOE supports DH group 14 key establishment
scheme that meets standard RFC 3526, section 3 for interoperability.
 NDcPP21:FCS_CKM.2: See NDcPP21:FCS_CKM.1
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 26 of 30
 NDcPP21:FCS_CKM.4: All data is cleared as identified above.
 NDcPP21:FCS_COP.1/DataEncryption: The TOE performs encryption and decryption using AES in CBC
mode with key sizes of either 128 or 256. The corresponding CAVP certificate is identified in the table
above.
 NDcPP21:FCS_COP.1/Hash: The TOE supports cryptographic hashing services using SHA-1 and SHA-256
with digest sizes 160 and 256. The corresponding CAVP certificate is identified in the table above,
 NDcPP21:FCS_COP.1/KeyedHash: The TOE supports keyed-hash message authentication using HMAC-
SHA-1 and HMAC-SHA-256, using SHA-1/256 with 160/256 bit keys to produce a 160/256 output MAC.
The corresponding CAVP certificate is identified in the table above
 NDcPP21:FCS_COP.1/SigGen: The TOE supports the use of RSA with 2048 bit key sizes for cryptographic
signatures. Digital signatures are used in TLS and SSH communications and on product updates. The
corresponding CAVP certificate is identified in the table above.
 NDcPP21:FCS_RBG_EXT.1: The TOE uses one software-based entropy source to seed for a software-based
DRBG that complies with Special Publication 800-90 using CTR_DRBG when operating in the FIPS mode.
AES-256 is used in conjunction with a minimum of 256 bits of entropy for the seed.
 NDcPP21:FCS_SSHS_EXT.1: The TOE supports SSHv2 as described above for CLI management.
 NDcPP21:FCS_TLSC_EXT.1: The TOE supports TLS v1.1 and v1.2 with the ciphersuites listed above for
its syslog connections. The TOE does not support certificate pinning.
6.3 Identification and authentication
The TOE requires users to be identified and authenticated before they can use functions mediated by the TOE, except
to display a message of the day banner and to permit network traffic to flow through the TOE without identification
or authentication. The TOE authenticates TOE Users against their user name, password and privilege level.
All users capable of logging into the TOE represents the “administrator” referred to in the security requirements of
the protection profile. Each user account has a user name, password, and a privilege level associated with it. While
the TOE utilizes the privilege level to distinguish between a Super User and other lesser privileged roles, the evaluation
utilized only the privileged super user accounts.
Note that the TOE supports a password enforcement configuration where the minimum password length can be set by
an administrator. The default minimum length is 8 and this can set to as high as 48 characters. Passwords can be
created using any alphabetic, numeric, and a wide range of special characters (identified in FIA_PMG_EXT.1).
Additional authentication mechanisms can also be configured by an Administrator using an Authentication Method
List. This allows some flexibility in setting up authentication mechanisms when desired. The available mechanisms
include the local accounts, the SSH public key authentication mechanism, TACACS+ based authentication and
RADIUS-based authentication. An administrator may upload a public key to be used with SSH client public key
authentication.
The Administrator can set a lockout failure count for remote login attempts (the default is 3 attempts). If the count is
exceeded, the account gets locked out until a local admin resets the lock using a CLI. The local administrator account
never gets locked out.
The TOE performs validation of a certificate including the following checks as appropriate:
 Verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose
in the extendedKeyUsage field.
 Verify a server certificate that contains a CN that does not match the reference identifier and does not contain
the SAN extension is rejected.
 Verify a server certificate that contains a CN that matches the reference identifier, contains the SAN
extension, but does not contain an identifier in the SAN that matches the reference identifier is rejected.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 27 of 30
 Verify a server certificate that contains a CN that does not match the reference identifier but does contain an
identifier in the SAN that matches is accepted.
 Verify wildcards are not supported.
 Verify the certificate chain is valid.
 Verify the expiration status of the certificate.
 Verify the revocation status of the certificate.
The Identification and authentication function satisfies the following security functional requirements:
 NDcPP21:FIA_AFL.1: The administrator can set a maximum remote login failure number in the range from
1 to 5 failed logins. The default value for this limit is 3. If the limit is exceeded, the account cannot be used
until the account is unlocked. An account can be unlocked by a TOE reboot, performing a login at the local
console using the locked account, or by another administrator explicitly unlocking the account. Accounts
are never locked from use at the local console.
 NDcPP21:FIA_PMG_EXT.1: The TOE implements a rich set of password composition constraints as
described above.
 NDcPP21:FIA_UAU.7: The TOE does not echo passwords as they are entered; rather ‘*’ characters are
echoed when entering password.
 NDcPP21:FIA_UAU_EXT.2: The TOE uses local password-based, SSH public key, TACACS+ based and
RADIUS-based authentication mechanisms to login authorized administrative users remotely and locally.
 NDcPP21:FIA_UIA_EXT.1: The TOE doesn’t offer any services or access to its functions, except for the
switching/routing of network traffic and displaying a message of the day banner, without requiring a user to
be identified and authenticated.
 NDcPP21:FIA_X509_EXT.1/Rev: The TOE uses the OCSP protocol for X509v3 certificate status
validation. Certificates are validated as part of the authentication process when they are presented to the TOE.
As described above, the following fields are verified as appropriate: SAN checks, CN checks, key usages,
basic constraints, chain validation, and expiration status. The common name (or SAN values if present) needs
to be an IP address. Wildcards are not allowed in certificates.
 NDcPP21:FIA_X509_EXT.2: Certificates are checked and if found not valid are not accepted or if the OCSP
server cannot be contacted for validity checks, then the certificate is not accepted.
6.4 Security management
The TOE associates each defined user account with a privilege level. The most privileged level is Super User (with
regards to the requirements in this Security Target users with lesser privilege levels are referred to collectively simply
as TOE users since such users do not have complete read-and-write access to the system). Again, as stated in section
6.3, other accounts with privileges other than Super User were not tested during the evaluation. The TOE implements
an internal access control mechanism that bases decisions about the use of functions and access to TOE data on those
privilege levels. In this manner, the TOE is able to ensure that only the Authorized Administrator with Super User
privilege can access audit configuration data, information flow policy ACLs, user and administrator security attributes
(including passwords and privilege levels), authentication method lists, the logon failure threshold, the remote access
user list; and cryptographic support settings.
Other than the Super User level, the TOE implements a Read Only level where only basic commands can be issued
and no changes can be made and a Port Configuration level where non-security device parameters can be managed.
Collectively, this ST refers to all users of the TOE as “TOE Users” where the “Authorized Administrator with Super
User privilege” is a subset of that broader role.
The TOE offers administrative operations which are accessible via the CLI (command line interface). The CLI is a
text based interface which can be accessed from a directly connected terminal or via a remote terminal using SSH.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 28 of 30
These command line functions can be used to effectively manage every security policy, as well as the non-security
relevant aspects of the TOE.
Once authenticated (none of these functions is available to any user before being identified and authenticated),
authorized administrators have access to the following security functions:
 Ability to administer the TOE locally and remotely;
 Ability to configure the access banner;
 Ability to configure the session inactivity time before session termination or locking;
 Ability to update the TOE, and to verify the updates using [digital signature] capability prior to installing
those updates;
 Ability to configure the authentication failure parameters for FIA_AFL.1;
 Ability to configure audit behavior,
 Ability to configure the list of TOE-provided services available before an entity is identified and
authenticated, as specified in FIA_UIA_EXT.1,
 Ability to re-enable an Administrator account,
 Ability to manage the cryptographic keys,
 Ability to configure the cryptographic functionality,
 Ability to configure thresholds for SSH rekeying,
 Ability to set the time which is used for time-stamps;
 Ability to import X509v3 certificates to the TOE's trust store
The Security management function satisfies the following security functional requirements:
 NDcPP21:FMT_MOF.1/ManualUpdate: Only the authorized administrator can update the TOE
 NDcPP21:FMT_MTD.1/CoreData: Security management is restricted to administrators
 NDcPP21:FMT_MTD.1/CryptoKeys: Mangement of cryptographic keys used by the TOE is restricted to
the administrator.
 NDcPP21:FMT_SMF.1: The TOE provides administrative local, serial console and remote, SSH command
line interfaces to perform the functions identified above.
 NDcPP21:FMT_SMR.2: The TOE maintains administrative user roles.
6.5 Protection of the TSF
The TOE is an appliance and as such is designed to work independent of other components to a large extent. While
the administrative interface is function rich, the TOE is designed specifically to not provide access to locally stored
passwords and cryptographic keys. Dynamically generated cryptographic keys, such as for SSH sessions, are stored
in RAM only. All cryptographic keys that are stored are in an area of the filesystem not accessible to users and no user
interface is provided to access the cryptographic keys. Cryptographic keys that are stored in the filesystem are
protected from access by administrators.
The TOE is a hardware appliance that includes a hardware-based real-time clock. The TOE’s embedded OS manages
the clock and exposes administrator clock-related functions. The TOE also implements the timing elements through
timeout functionality due to inactivity for terminating both local and remote sessions. Note that the clock is used
primarily to provide timestamp for audit records, but is also used to supporting timing elements of cryptographic
functions.
The TOE includes a number of built in diagnostic tests that are run during start-up to determine whether the TOE is
operating properly. The TOE will reboot when an error in self-testing is encountered. The module performs
Cryptographic algorithm known answer tests, firmware integrity tests using RSA signature verification and
conditional self-tests for DRBG. Upon failing any of its power-on self-tests, the TOE will refuse to boot.
The TOE supports loading a new software image manually by the administrator using CLI commands. From the CLI,
an administrator can obtain a software image. Prior to actually installing the image the TOE verifies the HMAC-
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 29 of 30
SHA-256 digital signature using the Extreme Network’s public key. An unverified image cannot be installed. The
TOE comes preinstalled with the Extreme Network’s public key
The Protection of the TSF function satisfies the following security functional requirements:
 NDcPP21:FPT_APW_EXT.1: The TOE does not offer any functions that will disclose to any user a plain
text password. Furthermore, locally defined passwords are not stored in plaintext form.
 NDcPP21:FPT_SKP_EXT.1: The TOE does not offer any functions that will disclose to any users a stored
cryptographic key.
 NDcPP21:FPT_STM_EXT.1: The TOE allows system administrators to set the time used by the TOE. This
time is used by the TOE for audit timestamps and certificate validation activities.
 NDcPP21:FPT_TST_EXT.1: The TOE includes a number of power-on diagnostics that will serve to ensure
the TOE is functioning properly. The tests include ensure memory and flash can be accessed as expected, to
ensure that software checksums are correct, and also to test the presence and function of plugged devices.
 NDcPP21:FPT_TUD_EXT.1: The TOE provides function to query the version and upgrade the software
embedded in the TOE appliance. When installing updated software, digital signatures are used to authenticate
the update to ensure it is the update intended and originated by Extreme,
6.6 TOE access
The TOE can be configured to display an administrator-configured message of the day banner that will be displayed
before authentication is completed (before the user enters his password). The banner will be displayed when accessing
the TOE via the console, or SSH interfaces.
The TOE can be configured by an administrator to set a session timeout value (any value up to 240 minutes, with 0
disabling the timeout, i.e., the default timeout is disabled) – the default timeout is disabled. A session (local or remote)
that is inactive (i.e., no commands issuing from the remote client) for the defined timeout value will be terminated.
Upon exceeding the session timeout (if set), the TOE logs the user off, but leaves the user’s console displaying the
last contents.
The user will be required to login in after any session has been terminated due to inactivity or after voluntary
termination. Of course, administrators can logout of local or remote sessions at any time.
The TOE access function satisfies the following security functional requirements:
 NDcPP21:FTA_SSL.3: The TOE terminates remote sessions that have been inactive for an administrator-
configured period of time.
 NDcPP21:FTA_SSL.4: The TOE provides the function to logout (or terminate) the both local and remote
user sessions as directed by the user.
 NDcPP21:FTA_SSL_EXT.1: The TOE terminates local sessions that have been inactive for an
administrator-configured period of time.
 NDcPP21:FTA_TAB.1: The TOE can be configured to display administrator-defined advisory banners when
administrators successfully establish interactive sessions with the TOE, allowing administrators to terminate
their session prior to performing any functions.
6.7 Trusted path/channels
The TOE implements SSHv2 which is required to be used for remote administration. When an administrator attempts
to connect to the TOE, the TOE attempts to negotiate a session. If the session cannot be negotiated, the connection is
dropped.
When a client attempts to connect using SSH, the TOE and the client will negotiate the most secure algorithms
available at both ends to protect that session.
Extreme Networks, Inc. NetIron with IronWare R06.3.00aa (NDcPP21) Security Target Version 0.4, September 9, 2019
Page 30 of 30
Remote connection to SYSLOG servers, TACACS+ servers and RADIUS servers are protected using TLS (as
specified earlier).
In all cases, the endpoints are assured by virtue of the certificates installed, trusted, and reviewable when connecting
and by virtue of user authentication.
The Trusted path/channels function satisfies the following security functional requirements:
 NDcPP21:FTP_ITC.1: In the evaluated configuration, the TOE must be configured to use TLS to ensure that
any authentication operations and exported audit records are sent only to the configured server so they are
not subject to inappropriate disclosure or modification.
 NDcPP21:FTP_TRP.1/Admin: The TOE provides SSH to ensure secure remote administration. In each case,
the administrator can initiate the remote session, the remote session is secured (disclosure and modification),
and all remote security management functions require the use of one of these secure channels.