Dell W-620 and W-650 Mobility Controllers with Dell AOS FIPS Firmware Non-Proprietary Security Policy FIPS 140-2 Level 2 January 26, 2015 This is to advise that the document entitled “Aruba 620 and 650 Mobility Controllers with ArubaOS FIPS Firmware Non-Proprietary Security Policy FIPS 140-2 Level 2” Version 3.2, dated July 2014, applies to Dell W-620 and W-650 Controllers with Dell AOS FIPS Firmware. Aruba Networks is the Original Equipment Manufacturer (OEM) for the Dell Networking W-Series of products.
Dell W-620 and W-650 Mobility Controller Product Images: Aruba 620 and 650 Mobility Controller Product Images: If you have questions or concerns, please contact Dell Technical Support at www.dell.com/support, additional product documentation is also available by device under user manuals.
Aruba 620 and 650 Mobility Controllers with ArubaOS FIPS Firmware Non-Proprietary Security Policy FIPS 140-2 Level 2 Version 3.
Copyright ® © 2014 Aruba Networks, Inc. Aruba Networks trademarks include , Aruba Networks , Aruba Wireless Networks®, the registered Aruba the Mobile Edge Company logo, Aruba Mobility Management System®, Mobile Edge Architecture®, ® ® ® People Move. Networks Must Follow , RFprotectrotect , Green Island . All rights reserved. All other trademarks are the property of their respective owners.
Contents Contents............................................................................................................................................................................. 3 Preface ............................................................................................................................................................................... 5 Purpose of this Document.............................................................................................................
Reading TELs ..............................................................................................................................................33 Required TEL Locations ..............................................................................................................................34 Aruba 620 .................................................................................................................................................................. 34 Aruba 650 ................
Preface This security policy document can be copied and distributed freely. Purpose of this Document This release supplement provides information regarding the Aruba 600 Series Controllers with FIPS 140-2 Level 2 validation from Aruba Networks. The material in this supplement modifies the general Aruba hardware and firmware documentation included with this product and should be kept with your Aruba product documentation.
Overview The Aruba 600 series Mobility Controllers are network infrastructure devices providing secure, scalable solutions for enterprise Wi-Fi, network security policy enforcement, VPN services, and wireless intrusion detection and prevention. Mobility controllers serve as central points of authentication, encryption, access control, and network coordination for all mobile network services.
Physical Description Cryptographic Module Boundaries For FIPS 140-2 Level 2 validation, the Mobility Controller has been validated as a multi-chip standalone cryptographic module. The chassis physically encloses the complete set of hardware and firmware components and represents the cryptographic boundary of the switch. The cryptographic boundary is defined as encompassing the top, front, left, right, rear, and bottom surfaces of the case.
Figure 2 ‐ Aruba 620 Mobility Controller Rear View Serial Console Port 10/100Base-T Ethernet Ports 10/100/1000Base-T Gigabit Ethernet Port Media Eject Button AC Power Socket USB port The Aruba 620 is equipped with a media eject button, which allows users to eject storage devices safely and place the system in standby.
Operating with NAS Media un-mounted Amber-solid Press and hold media eject button for more than 5 seconds only Red-flashing Controller goes into Standby Red-solid Standby Red-solid Press media eject button Amber-flashing Controller wake-up Green-solid Aruba 650 Chassis The Aruba 650 Mobility Controller chassis is also 1RU non-modular. The following diagrams (Figure 3 and Figure 4) show the front and rear view of the chassis respectively.
Antennae Interfaces (651 Only) ExpressCard Slot AC Power Socket The Aruba 650 Series is equipped with a media eject button, which allows users to eject storage devices safely and place the system in standby. Pushing the media eject button changes the state of the Aruba 650 Series; the table below describes the states and LED behaviors associated with use of the media eject button.
Operating with NAS Media un-mounted Amber-solid Press and hold media eject button for more than 5 seconds only Red-flashing Controller goes into Standby Red-solid Standby Red-solid Press media eject button Amber-flashing Controller wake-up Green-solid Aruba 600 Series Controllers FIPS 140-2 Level 2 Security Policy|11
Intended Level of Security The Aruba 620 and 650 Mobility Controllers are intended to meet overall FIPS 140-2 Level 2 requirements as shown in Table 1.
Physical Security The Aruba Controller is a scalable, multi-processor standalone network device and is enclosed in a robust housing. The controller enclosure is resistant to probing and is opaque within the visible spectrum. The enclosure of the module has been designed to satisfy FIPS 140-2 Level 2 physical security requirements. The Aruba 600 Series Controller requires Tamper-Evident Labels (TELs) to allow the detection of the opening of the chassis cover and to block the Serial console port.
Table 4 FIPS 140-2 Logical Interfaces Status Output Interface Power Interface 10/100 Mbps Ethernet Port 10/100/1000 Mbps Ethernet Port LEDs Serial Console port (disabled) Power Supply Power over Ethernet (PoE) Data input and output, control input, status output, and power interfaces are defined as follows: Data input and output are the packets that use the firewall, VPN, and routing functionality of the modules.
tools. The Web Interface can be accessed from a TLS-enabled Web browser using HTTPS (HTTP with Secure Socket Layer) on logical port 4343. SNMP v3 The Crypto Officer can also use SNMPv3 to remotely perform non-security-sensitive monitoring using the ‘get’ and ‘getnext’ commands. See the table below for descriptions of the services available to the Crypto Officer role. Table 5 ‐ Crypto-Officer Services Service Description Input Output CSP Access SSH v2.
Table 5 ‐ Crypto-Officer Services Configuring Module Platform Define the platform subsystem firmware of the module by entering Bootrom Monitor Mode, File System, fault report, message logging, and other platform related commands Commands and configuration data Status of commands and configuration data None Configuring Hardware Controllers Define synchronization features for module Commands and configuration data Status of commands and configuration data None Configuring Internet Protocol Set IP
Table 5 ‐ Crypto-Officer Services HTTPS over TLS Secure browser connection over Transport Layer Security acting as a Crypto Officer service (web management interface) TLS inputs, commands, TLS outputs, and data status, and data 29, 30, 31, 32 (read) 26, 27, 28 (read/write) Status Function Cryptographic officer may use CLI "show" commands or view WebUI via TLS to view the controller configuration, routing tables, and active sessions; view health, temperature, memory status, voltage, and packet statisti
Table 5 ‐ Crypto-Officer Services Zeroization Zeroizes all flash memory Command status, and data and configuration data, self signed certificates 18, 19, 20, 21, 22, 23 (read/write) Progress information All CSPs will be destroyed. User Role The User role can access the controller’s IPSec and IKEv1/IKEv2 services.
802.11i Shared Key Mode Access the module’s 802.11i services in order to secure network traffic 802.11i inputs, commands and data 802.11i outputs, status and data 33 (read) 35 (read/write) 802.11i with EAPTLS Access the module’s 802.11i services in order to secure network traffic 802.11i inputs, commands and data 802.
140-2. RSA-based authentication (IKEv1/IKEv2) User When using RSA based authentication, RSA key pair has modulus size of 2048 bits, thus providing 112 bits of strength. Assuming the low end of that range, the associated probability of a successful random attempt is 1 in 2^112, which is less than 1 in 1,000,000 required by FIPS 140-2. ECDSA-based authentication (IKEv1/IKEv2) User ECDSA signing and verification is used to authenticate to the module during IKEv1/IKEv2.
VLAN service Network bridging service Network Address Resolution Protocol (ARP) service Packets routing, switching and forwarding Cryptographic Key Management Implemented Algorithms FIPS-approved cryptographic algorithms have been implemented in firmware and hardware. Hardware encryption acceleration is provided for bulk cryptographic operations for the following FIPS approved algorithms: o o o o AES (Cert. #779) Triple-DES (Cert. #673) SHS (Cert. #781) HMAC (Cert.
o o SHS (Cert. #2246) Triple-DES (Cert. #1605) Note: o RSA (Cert. #1376; non-compliant with the functions from the CAVP Historical RSA List) FIPS186-2: ALG[ANSIX9.31]: Key(gen)(MOD: 1024 PubKey Values: 65537) ALG[RSASSA-PKCS1_V1_5]: SIG(gen): 1024, SHS: SHA-1/SHA-256/SHA-384/SHA512, 2048, SHS: SHA-1 o ECDSA (Cert.
Table 8 ‐ CSPs/Keys Used in Aruba Controllers 1 Key Encryption Key (KEK) Triple-DES 168-bit key Hardcoded during manufacturing Stored in Flash. Zeroized by using command ‘wipe out flash’ Encrypts IKEv1/IKEv2 Pre-shared key, RADIUS server shared secret, RSA private key, ECDSA private key, 802.11i pre-shared key and Passwords. 2 DRBG entropy input SP800-90a DRBG (512 bits) Derived using NONFIPS approved HW RNG Stored in plaintext in volatile memory. Zeroized on reboot.
Table 8 ‐ CSPs/Keys Used in Aruba Controllers 8 Diffie-Hellman private key Diffie-Hellman private key (224 bits) Generated internally during Diffie-Hellman Exchange Stored in the volatile memory. Zeroized after the session is closed. Used in establishing the session key for an IPSec session 9 Diffie-Hellman public key Diffie-Hellman public key (2048 bits) Generated internally during Diffie-Hellman Exchange Stored in the volatile memory. Zeroized after the session is closed.
Table 8 ‐ CSPs/Keys Used in Aruba Controllers 15 Enable secret 8-64 character password CO configured Store in ciphertext in flash. Zeroized by changing (updating) through the user interface. Administrator authentication 16 User Passwords 8-64 character password CO configured Stored encrypted in Flash with KEK. Zeroized by either deleting the password configuration file or by overwriting the password with a new one.
Table 8 ‐ CSPs/Keys Used in Aruba Controllers 22 IPSec session encryption keys Triple-DES (168 bits / AES (128/196/256 bits – 3 key Triple-DES only) Established during the IPSec service implementation Stored in plaintext in volatile memory. Zeroized when the session is closed. Secure IPSec traffic 23 IPSec session authentication keys HMAC-SHA-1 (160 bits) Established during the IPSec service implementation Stored in plaintext in volatile memory. Zeroized when the session is closed.
Table 8 ‐ CSPs/Keys Used in Aruba Controllers 30 RSA Public key RSA 2048 bit public key Generated in the module Stored in flash memory encrypted with KEK. Zeroized by the CO command write erase all. Used by TLS and EAP-TLS/PEAP protocols during the handshake, used for signing OCSP responses, and used by IKEv1/IKEv2 for device authentication and for signing certificates 31 ECDSA Private Key ECDSA suite B P-256 and P-384 curves Generated in the module Stored in flash memory encrypted with KEK.
Table 8 ‐ CSPs/Keys Used in Aruba Controllers 38 SNMPv3 session key AES-CFB key (128 bits) Derived from SNMPv3 privacy password using an approved KDF Stored in volatile memory. Zeroized on reboot. Secure channel for SNMPv3 management Self-Tests The Aruba Controller performs both power-up and conditional self-tests. In the event any self-test fails, the controller will enter an error state, log the error, and reboot automatically.
CRNG Test to Approved RNG (DRBG) ECDSA Pairwise Consistency Test RSA Pairwise Consistency Test ArubaOS Crypto Module CRNG Test to Approved RNG (FIPS 186-2 RNG) ECDSA Pairwise Consistency Test RSA Pairwise Consistency Test ArubaOS Uboot BootLoader Module Firmware Load Test - RSA PKCS#1 v1.5 (2048 bits) signature verification Conditional Tests on Hardware: CRNG Test to non-Approved RNGs Self-test results are logged in a log file.
30| Aruba 600 Series Controllers FIPS 140-2 Level 2 Security Policy
Installing the Controller This chapter covers the physical installation of the Aruba 620 and 650 Mobility Controllers with FIPS 140-2 Level 2 validation. The Crypto Officer is responsible for ensuring that the following procedures are used to place the controller in a FIPS-approved mode of operation.
Comply with electrical grounding standards during all phases of installation and operation of the product. Do not allow the controller chassis, network ports, power supplies, or mounting brackets to contact any device, cable, object, or person attached to a different electrical ground. Also, never connect the device to external storm grounding sources. Installation or removal of the chassis or any module must be performed in a static-free environment.
Tamper-Evident Labels After testing, the Crypto Officer must apply Tamper-Evident Labels (TELs) to the controller. When applied properly, the TELs allow the Crypto Officer to detect the opening of the chassis cover, the removal or replacement of modules or cover plates, or physical access to restricted ports. Vendor provides FIPS 140 designated TELs which have met the physical security testing requirements for tamper evident labels under the FIPS 140-2 Standard.
Required TEL Locations Aruba 620 This sections displays all the TEL locations on the Aruba 620. The Aruba 620 requires a minimum of 8 TELs to be applied as follows: To detect opening of the chassis cover: 1. Spanning the front face plate and left and bottom chassis cover 2. Spanning the front face plate and top chassis cover 3. Spanning the front face plate and bottom chassis cover 4. Spanning the front face plate and right and bottom chassis cover 5.
Figure 7 ‐ Aruba 620 — Left‐side view Figure 8 ‐ Aruba 620 — Right‐side view Figure 9 ‐ Aruba 620 — Top view Aruba 600 Series Controllers FIPS 140-2 Level 2 Security Policy|35
Figure 10 ‐ Aruba 620 — Bottom view Aruba 650 This sections displays all the TEL locations on the Aruba 650. The Aruba 650 requires a minimum of 8 TELs to be applied as follows: To detect opening of the chassis cover: 1. Spanning the front face plate and left chassis cover 2. Spanning the front face plate and bottom chassis cover 3. Spanning the front face plate and right chassis cover 4.
6. Spanning the left chassis cover and top chassis cover 7. Spanning the front face plate and bottom chassis cover 8. Spanning the rear face plate and bottom chassis cover To detect access to restricted ports: 2. Spanning the serial port 5.
Figure 14 ‐ Aruba 650 — Right‐side view Figure 15 ‐ Aruba 650 — Top view Figure 16 ‐ Aruba 650 — Bottom view 38| Aruba 600 Series Controllers FIPS 140-2 Level 2 Security Policy
Applying TELs The Crypto Officer should employ TELs as follows: Before applying a TEL, make sure the target surfaces are clean and dry. Do not cut, trim, punch, or otherwise alter the TEL. Apply the wholly intact TEL firmly and completely to the target surfaces. Press down firmly across the entire label surface, making several back-and-forth passes to ensure that the label securely adheres to the chassis. Ensure that TEL placement is not defeated by simultaneous removal of multiple modules.
User Guidance The User accesses the controller VPN functionality as an IPsec client. The user can also access the controller 802.11i functionality as an 802.11 client. Although outside the boundary of the controller, the User should be directed to be careful not to provide authentication information and session keys to others parties.
Setup and Configuration The Aruba 600 Series Controllers meet FIPS 140-2 Level 2 requirements. The sections below describe how to place and keep the controller in FIPS-approved mode of operation. The Crypto Officer (CO) must ensure that the controller is kept in a FIPS-approved mode of operation. The controller can operate in two modes: the FIPS-approved mode, and the standard non-FIPS mode. By default, the controller operates in non-FIPS mode. Setting Up Your Controller To set up your controller: 1.
Configuration Saved. To verify that FIPS mode has been enabled, issue the command “show fips”.