Specifications
Brocade MLXe® and NetIron® Family Devices with Multi-Service IronWare R05.7.00
Security Target Version 1., July 15, 2014
Page 45 of 50
The Cryptographic support function is designed to satisfy the following security functional requirements:
• FCS_CKM.1: See Table 6 NIST SP800-56B Conformance above.
• FCS_CKM_EXT.4: Keys are zeroized when they are no longer needed by the TOE.
• FCS_COP.1(1): See Table 5 Cryptographic Functions above.
• FCS_COP.1(2): See Table 5 Cryptographic Functions above.
• FCS_COP.1(3): See Table 5 Cryptographic Functions above.
• FCS_COP.1(4): See Table 5 Cryptographic Functions above.
• FCS_HTTPS_EXT.1: The TOE supports TLS/HTTPS web-based secure administrator sessions.
• FCS_RBG_EXT.1: See Table 5 Cryptographic Functions above.
• FCS_SSH_EXT.1: The TOE supports SSHv2 interactive command-line secure administrator sessions as
indicated above.
• FCS_TLS_EXT.1: The TOE supports TLS/HTTPS web-based secure administrator sessions.
6.3 User data protection
The TOE is designed to ensure its own internal integrity as well as to protect user data from potential, unintended
reuse by clearing resources (e.g., memory) as they are allocated to create objects used in the implementation of the
TOE operations. Note that volatile memory is the primary resource involved in normal TOE execution while its
persistent storage is based on non-volatile flash memory.
When the TOE sends a network packet, it must request a buffer from the buffer pool. After using a buffer, the TOE
releases the buffer back to the buffer pool. In response to a request, the buffer pool will return a buffer and its
length, where the length is greater than or equal to that requested. The TOE will compare the length of the returned
buffer to that which it requested (the size of the packet), overwrite the returned buffer with packet data (destroying
any residual data present in the buffer), and, if the provided buffer exceeds the requested size of the packet,
overwrite any extra space with zeros (thus ensuring that no residual data can leak from the TOE).
The User data protection function is designed to satisfy the following security functional requirements:
• FDP_RIP.2: The TOE always overwrites resources when allocated for use in objects.
6.4 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 network routing services that the TOE allows includes network traffic being
routed through the TOE as well as network routing protocol traffic destined to the TOE (including DNS, ARP,
ICMP, BootP, DHCP, RIP, OSPF, BGP, VRRP, VRRP-E, Multi-VRF) but does not include any management
configuration of the TOE’s network routing services. The TOE authenticates TOE Users against their user name,
password and privilege level.
The Authorized Administrator with Super User privilege represents the “administrator” referred to in the security
requirements of the protection profile. Other accounts with privileges other than Super User were not testing during
evaluation. The Authorized Administrator with Super User privilege defines local user (or TOE User) accounts and
to assign passwords and privilege levels to the accounts. Each user account has a user name, password, and a
privilege level associated with it. There is a default privilege level account associated with each privilege level and
each has its own password. It is up to the Authorized Administrator with Super User privilege to decide whether or
how to use these legacy accounts. Note however, that each has an identity, password, and privilege level.