Specifications

Security Target Version 1.0 9/29/2014
71
• FCS_CKM.1(1): See table above.
• FCS_CKM.1(2): See table above.
• FCS_CKM.2(1): See table above.
• FCS_CKM.2(2): See table above.
• FCS_CKM_EXT.4: Keys are zeroized when they are no longer needed by the TOE
• FCS_COP.1(1): See table above.
• FCS_COP.1(2): See table above.
• FCS_COP.1(3): See table above.
• FCS_COP.1(4): See table above.
• FCS_COP.1(5): See table above.
• FCS_HTTPS_EXT.1: The TOE supports TLS/HTTPS web-based secure administrator sessions.
• FCS_IPSEC_EXT.1: The TOE supports IPsec cryptographic network communication protection (RFC
4868, RFC 4945).
• FCS_RBG_EXT.1: See table 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
Network packets are received in memory buffers pre-allocated at boot time. The buffers are populated in the
network interface receive ring. When the CPU receives network packets from the network interface, the CPU
allocates a free buffer from the preallocated pool and replenishes the receive ring. When the CPU has finished
packet processing, the CPU adds the memory buffer associated with this network packet to the free buffer pool.
Packets read from the buffers are always the same size as those written, so no explicit zeroing or overwriting of
buffers on allocation is required.
Each pre-allocated memory buffer is fixed at 1792 bytes, and is sufficient to hold a standard Ethernet frame. When
a frame is received by the network interface, a proprietary header is prepended onto the frame indicating its length,
among other parameters. The frame is then sent to the CPU. The CPU reads the length out of the proprietary header
and uses this to process the frame out of the buffer. For standard Ethernet frames, only a single frame is placed into
a memory buffer – buffers do not contain multiple frames.
Jumbo packets are supported – these must be split across multiple memory buffers. The proprietary header ensures
that the packet is reconstructed correctly.
The length in the proprietary header is always correct – the product would not function if this were not the case.
The User data protection function is designed to satisfy the following security functional requirements:
• FDP_RIP.2: Packets read from the buffers are always the same size as those written, so no explicit zeroing
or overwriting of buffers on allocation is required (i.e., packet content is always overwritten before being
read).
6.4 Identification and authentication
The TOE supports role-based authentication. Wireless users (or clients, term used interchangeably) can authenticate
to an external authentication server or to the Controller’s internal database. The administrator can create a user