Aruba 3000 and 6000/M3  Revision B2 Controllers with ArubaOS FIPS Firmware Non- Proprietary Security Policy FIPS 140-2 Level 2 Release Supplement Copyright © 2012 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 , RFProtect , Green Island . All rights reserved. All other trademarks are the property of their respective owners. Open Source Code Certain Aruba products include Open Source software code developed by third parties, including software code subject to the GNU General Public License (GPL), GNU Lesser General Public License (LGPL), or other Open Source Licenses. The Open Source code used can be found at this site: http://www.arubanetworks.com/open_source Legal Notice The use of Aruba Networks, Inc. switching platforms and software, by all individuals or corporations, to terminate other vendors’ VPN client devices constitutes complete acceptance of liability by that individual or corporation for this action and indemnifies, in full, Aruba Networks, Inc. from any and all legal actions that might be taken against it with respect to infringement of copyright on behalf of those vendors. Warranty This hardware product is protected by the standard Aruba warranty of one year parts/labor. For more information, refer to the ARUBACARE SERVICE AND SUPPORT TERMS AND CONDITIONS. Altering this device (such as painting it) voids the warranty. www.arubanetworks.com 1344 Crossman Avenue Sunnyvale, California 94089 Phone: 408.227.4500 Fax 408.227.4550 0510541-16 | November 2012 Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 2|             Preface .................................................................................................................................................................................... 5  Purpose of this Document ............................................................................................................................................... 5  Related Documents ......................................................................................................................................................... 7  Additional Product Information ......................................................................................................................7  The Aruba 3000 and 6000/M3 Controllers ....................................................................................................................... 8  Overview ............................................................................................................................................................................ 8  Physical Description  ........................................................................................................................................................ 9  . Dimensions ....................................................................................................................................................9  Cryptographic Module Boundaries ..............................................................................................................10  Chassis ........................................................................................................................................................10  FIPS 140-2 Level 2 Features............................................................................................................................................ 14  Intended Level of Security ............................................................................................................................................ 14  Physical Security ............................................................................................................................................................ 15  Operational Environment .............................................................................................................................................. 15  Logical Interfaces ........................................................................................................................................................... 15  Roles and Services ........................................................................................................................................................ 17  Crypto Officer Role ......................................................................................................................................17  User Role.....................................................................................................................................................20  Authentication Mechanisms.........................................................................................................................21  Unauthenticated Services............................................................................................................................22  Cryptographic Key Management ................................................................................................................................. 23  Implemented Algorithms ..............................................................................................................................23  Non-FIPS Approved Algorithms ........................................................................................................23  Critical Security Parameters ........................................................................................................................24  Self-Tests  ........................................................................................................................................................................ 28  . Alternating Bypass State ............................................................................................................................................... 30  Mitigation of Other Attacks ............................................................................................................................................ 30  XSec ............................................................................................................................................................30  Wireless Intrusion Detection ........................................................................................................................30  Unique Station and User Classification .............................................................................................................. 31  Detecting and Disabling Rogue APs ................................................................................................................... 31  Denial of Service and Impersonation Protection .........................................................................................31  Man-in-the-Middle Protection ......................................................................................................................31  Policy Definition and Enforcement ...............................................................................................................32  Using Wireless to Protect your Wired Network ............................................................................................32  Using Wireless to Protect your Existing Wireless Network ..........................................................................32  Installing the Controller ...................................................................................................................................................... 33  Pre-Installation Checklist ............................................................................................................................................... 33  Precautions ..................................................................................................................................................................... 33  Product Examination ...................................................................................................................................34  Package Contents .......................................................................................................................................34  Minimum Configuration for the Aruba 6000-400 ..........................................................................................34  Tamper-Evident Labels ................................................................................................................................................. 35  Reading TELs ..............................................................................................................................................35  Required TEL Locations ..............................................................................................................................35  To Detect Opening the Chassis Cover ............................................................................................................... 36  To Detect the Removal of Any Module or Cover Plate  .................................................................................... 36  . To Detect Access to Restricted Ports ................................................................................................................. 36  To Detect Access to Restricted Port ................................................................................................................... 36  To Detect Opening the Chassis Cover ............................................................................................................... 36  Applying TELs .............................................................................................................................................36  Ongoing Management ....................................................................................................................................................... 38  Crypto Officer Management  ......................................................................................................................................... 38  . User Guidance ................................................................................................................................................................ 38  Setup and Configuration ................................................................................................................................................... 39  Setting Up Your Controller ............................................................................................................................................ 39  Enabling FIPS Mode ...................................................................................................................................................... 39  Enabling FIPS with the Setup Wizard ..........................................................................................................39  Enabling FIPS with the WebUI ....................................................................................................................39  Disallowed FIPS Mode Configurations ....................................................................................................................... 40    Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 4|       Preface  This security policy document can be copied and distributed freely. Purpose of this Document This release supplement provides information regarding the Aruba 3000 and 6000/M3 Controller 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. This supplement primarily covers the non-proprietary Cryptographic Module Security Policy for the Aruba Controller. This security policy describes how the switch meets the security requirements of FIPS 140-2 Level 2 and how to place and maintain the switch in a secure FIPS 140-2 mode. This policy was prepared as part of the FIPS 140-2 Level 2 validation of the product. FIPS 140-2 (Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Web-site at: http://csrc.nist.gov/groups/STM/cmvp/index.html Table 1 Aruba Legacy Controllers Supported but No Longer Sold Aruba Part Number Aruba Firmware 3200-USF1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS 3400-USF1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS 3600-USF1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS 3200-F1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS 3400-F1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS 3600-F1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS M3mk1-S-F1 Revision B2 ArubaOS_MMC_6.1.2.3-FIPS LC-2G-1 ArubaOS_MMC_6.1.2.3-FIPS LC-2G24F-1 ArubaOS_MMC_6.1.2.3-FIPS Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |5     Tab 1 Aruba Le ble egacy Contro ollers Supporte but No ed Long Sold ger LC-2 2G24FP-1 ArubaOS_MMC A C_6.1.2.3-FIPS S Aruba part numbers have XL processor v LR version varieties, which includ the use of t des the XLR Rev. B2 processor. The XLR Rev. B2 processor is n longer sold. A B2 unit can b e no be identified by a serial number beginning with an A. r h Controller mod dels (3200/340 00/3600) and coontroller chass (6000-400) e sis ending with -USSF1 are to be sold in the US only Controller mo y. odels ending w -F1 are con with nsidered ‘rest o of the world’ and must not be u d used for deploy yment in the Unnited States. Fr rom FIPS perspective, both -USF1 and -F1 controller and chassis are identical an fully FIPS b d rs nd compliant. Pleease notice that M3mk1-S-F1 hardware mod dule listed in Taable 1 above is s not a controlle and the unit h been available throughou the world. er has ut Aruba 6000-40 00-F1 and Aruba 6000-400-U USF1 listed in T Table 1 are the part numbers for e Aruba 6000-40 controller ch 00 hassis, where c host M3mk can k1-S-F1 Revision B2, LC-2G G-1, LC-2G24F-1 and LC-2G24FP-1 line cards. a Aruba Line Caards LC-2G-1, LC-2G24F-1 and LC2G24FP are no longe sold by Arub P-1 er ba, but are supported by the Aru 6000-400 c uba chassis until No ovember 1, 201 These optio 15. onal line cards can be replaced by the hardware M3mk1-S-F1 Revision B2 (n longer sold) e no ). Please notice that none of th Aruba Line c he cards (LC-2G-1 LC-2G24F-1 and LC2G24F 1, FP- 1) performs cr ryptographic opperations. Aruba 30 and 6000/M3 |FIPS 140-2 Le 000 3 evel 2 Release Supplement 6|       Related Documents The following items are part of the complete installation and operations documentation included with this product: • Aruba 6000 Mobility Controller Installation Guide • Aruba 3000-series Mobility Controller Installation Guide • ArubaOS 6.1 User Guide • ArubaOS 6.1 CLI Reference Guide • ArubaOS 6.1 Quick Start Guide • ArubaOS 6.1 Upgrade Guide • Aruba AP Installation Guides Additional Product Information More information is available from the following sources: • The Aruba Networks Web-site contains information on the full line of products from Aruba Networks: http://www.arubanetworks.com • The NIST Validated Modules Web-site contains contact information for answers to technical or sales-related questions for the product: http://csrc.nist.gov/groups/STM/cmvp/index.html       Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |7           The Aruba 3000 and 6000/M3 Controllers This chapter introduces the Aruba 3000 and 6000/M3 Controllers with FIPS 140-2 Level 2 validation. It describes the purpose of the controller, its physical attributes, and its interfaces. Overview Aruba Networks has developed a purpose-built Wireless LAN voice and data switching solution designed to specifically address the needs of large-scale WiFi network deployments for Government agencies and global enterprises. The Aruba Controller solution provides advanced security and management of the corporate RF environment and enforces User security and service policies to both wired and wireless users. The Aruba Wireless FIPS 140-2 Level 2 validated Controlling platform serves value-add high speed data and QoS assured voice services to thousands of mobile wireless users simultaneously from a single, cost effective, redundant and scalable solution that performs centralized functionality for: Uncompromised User security, authentication and encryption Stateful LAN-speed firewalling VPN termination Wireless intrusion detection, prevention and rogue containment RF Air monitoring Powerful packet processing switching Mobility management Advanced RF management Advanced User and network service / element management The Aruba FIPS 140-2 Level 2 validated Controller solution is a highly available, modular and upgradeable switching platform which connects, con-trols, secures, and intelligently integrates wireless Access Points and Air Monitors into the wired LAN, serving as a gateway between a wireless network and the wired network. The wireless network traffic from the APs is securely tunneled over a L2/L3 network and is terminated centrally on the switch via 10/100/1000 Ethernet physical interfaces where it is authenticated, assigned the appropriate security policies and VLAN assignments and up-linked onto the wired network. The Aruba Controller solution consists of the three major components: Aruba Controller. This is an enterprise-class switch into which multiple Access Points (APs) and Air Monitors (AMs) may be directly or in-directly (tunneled over a L2/L3 network) connected and controlled. Aruba Wireless Access Point. This is a next-generation wireless transceiver which func- tions as an AP or AM. Although third-party APs can be used with the Aruba WLAN sys-tem, the Aruba AP provides the most comprehensive features and simpler integration. Aruba ArubaOS Switch firmware. This firmware intelligently integrates the Controller and APs to provide load balancing, rate limiting, self-healing, authentication, mobility, security, firewalls, encryption, and centralization for monitoring and upgrades. The Aruba switch configurations validated during the cryptographic module testing included: Aruba 3200 Revision B2 Aruba 3400 Revision B2 Aruba 3600 Revision B2 There is one version of the M3mk1-S-F1 in this document: Revision B2. Revision B2 does not support AES-GCM (see “ Cryptographic Key Management ” on page 21 for more information). Revision B2 is no longer sold. Aruba 6000-400 chassis (no more than four Aruba line cards, including the combinations among M3mk1-S-F1 [Revision B2 ], LC-2G-1, LC-2G24F-1, or LC-2G24FP-1, in a single hardware configuration). Please notice that the use of LC-2G-1, LC-2G24F-1 and LC- 2G24FP-1 is optional, but at least one M3mk1-S-F1 is required in a single hardware configuration). The exact firmware version validated was ArubaOS_MMC_6.1.2.3-FIPS Physical Description Dimensions The Aruba 6000-400 controller chassis has the following physical dimensions: • 3 RU chassis is designed to fit in a standard 19" rack. A separate mounting kit is needed for a 23" rack. • Size: Width 17.4" (19" rack width) Height 5.25" (3 RU)— 3 .5" for the card slots plus 1 RU for the power supply slots Depth 14" • Maximum weight: Up to 58 lbs (26.5 kg) The Aruba 3200 Controller has the following physical dimensions: • 1 RU chassis is designed to fit in a standard 19" rack with the included mounting kit. A separate mounting kit is needed for a 23" rack. • Size: Width 13.8" Height 1.75" (1 RU) Depth 11.7" • Maximum weight: Up to 7.1 lbs (3.2 kg) The Aruba 3400 and 3600 Controllers have the following physical dimensions: Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |9     • 1 RU chassi is desig is gned to fi in a sta it andard 19" rack with the included mount h ting kit. A separate mounting kit is nee k eded for a 23" rack. • Si ize: Width 13.8" h Heigh 1.75" (1 RU) ht 1 Depth 11.7" h • Ma aximum wei ight: Up to 7.4 lbs (3.4 kg) o Cryp ptographic Module Boundaries c B s For FIPS 140-2 Level 2 validation the Con n, ntroller ha been va as alidated as a multi-chip s stan ndalone cry yptographi module. The steel chassis p ic l physically encloses the compl y lete set of f hard dware (including sup pervisor ca ards, line cards, th fan tra and the power sup e he ay pplies util lized within Aruba 6000-400 co 6 ontroller) and firmw ware compo onents and represent the ts cryp ptographic boundary of the switch. The cryptograp phic bound dary is def fined as enco ompassing the top, front, left, right, rear, and bottom su f urfaces of the chass sis. Cha assis The Aruba 6000-400 cont troller cha assis is d designed to be modul o lar. All of the modu f ular comp ponents, consisting of the switching su upervisor a and networ line car rk rds, the f fan tray, and the power supplies, are accessible fro the fron of the chassis. om nt Figur re 1 The Arub 6000-400 controller cha ba c assis with M3 Mark I ure 1 shows the fron of the A nt Aruba 6000 controlle chassis and illu 0 er s, ustrates t the Figu foll lowing: • In each Aru n uba 6000-40 00-F1 or A Aruba 6000- -400-USF1 controller chassis: r One M3 3mk1-S-F1 Revision B card is required to be installed in slot 0. B2 Up to three Aru uba line ca ards (the combinatio of LC-2G-1, LC-2G on G24F-1, LC-2G24FP-1, M3mk1- -S-F1 Revision B2 ca ard) can be installe in slots 1, 2 and 3 respectively ed d able 2 bel low lists a detailed line card configu d ds uration in a single Aruba 6000 0-400-F1 Ta or Aruba 60 r 000-400-USF control F1 ller chassi is Tab 2 6000-40 ble 00-F1 or 6000-400-USF1 Controller Ch hassis Con nfigurations Slot 0 Slot 1 Slot 2 Slo 3 ot M3m mk1-S-F1 x x x Aruba 30 and 6000/M3 |FIPS 140-2 Le 000 3 evel 2 Release Supplement 10|       Table 2 6000-400-F1 or 6000-400-USF1 Controller Chassis Configurations M3mk1-S-F1 LC-2G-1 x x M3mk1-S-F1 LC-2G-1 LC-2G-1 x M3mk1-S-F1 LC-2G-1 LC-2G-1 LC-2G-1 M3mk1-S-F1 LC-2G-1 LC-2G24F-1 x M3mk1-S-F1 LC-2G-1 LC-2G24F-1 LC-2G24F-1 M3mk1-S-F1 LC-2G-1 LC-2G24F-1 LC-2G24FP-1 M3mk1-S-F1 LC-2G-1 LC-2G24FP-1 x M3mk1-S-F1 LC-2G-1 LC-2G24FP-1 LC-2G24FP-1 M3mk1-S-F1 LC-2G24F-1 x x M3mk1-S-F1 LC-2G24F-1 LC-2G24F-1 x M3mk1-S-F1 LC-2G24F-1 LC-2G24F-1 LC-2G24F-1 M3mk1-S-F1 LC-2G24F-1 LC-2G24F-1 LC-2G24FP-1 M3mk1-S-F1 LC-2G24F-1 LC-2G24FP-1 LC-2G24FP-1 M3mk1-S-F1 LC-2G24FP-1 x x M3mk1-S-F1 LC-2G24FP-1 LC-2G24FP-1 x M3mk1-S-F1 LC-2G24FP-1 LC-2G24FP-1 LC-2G24FP-1 M3mk1-S-F1 M3mk1-S-F1 x x M3mk1-S-F1 M3mk1-S-F1 LC-2G-1 x M3mk1-S-F1 M3mk1-S-F1 LC-2G-1 LC-2G-1 M3mk1-S-F1 M3mk1-S-F1 LC-2G-1 LC-2G24F-1 M3mk1-S-F1 M3mk1-S-F1 LC-2G-1 LC-2G24FP-1 M3mk1-S-F1 M3mk1-S-F1 LC-2G24F-1 x M3mk1-S-F1 M3mk1-S-F1 LC-2G24F-1 LC-2G24F-1 M3mk1-S-F1 M3mk1-S-F1 LC-2G24F-1 LC-2G24FP-1 M3mk1-S-F1 M3mk1-S-F1 LC-2G24FP-1 x M3mk1-S-F1 M3mk1-S-F1 LC-2G24FP-1 LC-2G24FP-1 Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |11     Tab 2 6000-40 ble 00-F1 or 6000-400-USF1 Controller Ch hassis Con nfigurations M3m mk1-S-F1 M3mk1-S-F1 M3mk1- -S-F1 x M3m mk1-S-F1 M3mk1-S-F1 M3mk1- -S-F1 LC C-2G-1 M3m mk1-S-F1 M3mk1-S-F1 M3mk1- -S-F1 LC C-2G24F-1 M3m mk1-S-F1 M3mk1-S-F1 M3mk1- -S-F1 LC C-2G24FP-1 M3m mk1-S-F1 M3mk1-S-F1 M3mk1- -S-F1 M3 3mk1-S-F1 An ” x ” repres sents an em mpty slot. . Status indicator LED indicate power st S Ds e tate, statu of the device, an link ac us nd ctivity. Fan Tray is required for the A F d Aruba 6000 0-400 contr roller. It can be re t eplaced if needed f and it is Crypto Off a ficer’s responsibili ity to repl lace and i install the new Fan Tray. In e addition, HW-FT is the part nu a t umber for the fan tr ray used i the Arub 6000-40 in ba 00-F1 and Aruba 6000-400-USF1 chassis. A PS1, PS2, and PS3 ar for Powe Supply modules. T P re er The number of power supplies required r for the system depen f nds on the number of Line Card install f ds led, and wh hether to include redundancy for fault tolerance (please refer to t r t e the Aruba 6000 Mobil lity Contr roller Installati I ion Guide). It is Cry . ypto Offic cer’s respo onsibility to instal the pow y ll wer supplies. The two av s vailable po ower suppl lies are: 200 W Power Suppl (HW-PSU-200) ly 400 W Power Suppl (HW-PSU-400) ly When using more than one power supply, verify tha they ar all of t W n at re the same t type. Do not mix 200 W and 40 W power supplies in the sam chassis n 00 me s. HW-PSU-400 and HW-PSU- -200 are the pa numbers for the power sup art r pply used with the Aruba 6000-40 00-F1 or the Aruba 6000-400 0-USF1 chassis s. The Aruba 3000-seri ies Contr roller ch hassis is a 1U no s ot-modula chassi ar is. Figur 2 The Arub 3000-serie Controller Chassis re ba es Aruba 30 and 6000/M3 |FIPS 140-2 Le 000 3 evel 2 Release Supplement 12|       Figure 2 shows the front of the Aruba 3000-series Controller, and illustrates the following: • System indicator LEDs indicate power state and status of the device. • Four Gigabit Ethernet ports provide network connectivity. • Optional 1000Base-X fiber optic ports provide network connectivity. • Serial Console port is for connecting to a local management console.                               Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |13           FIPS 140-2 Level 2 Features Intended Level of Security The Aruba 3000 and 6000/M3 Controllers and associated modules are intended to meet overall FIPS 140-2 Level 2 requirements as shown in Table 1.B Table 3 Intended Level of Security Section Section Title Level 1 Cryptographic Module Specification 2 2 Cryptographic Module Ports and Interfaces 2 3 Roles, Services, and Authentication 2 4 Finite State Model 2 5 Physical Security 2 6 Operational Environment N/A 7 Cryptographic Key Management 2 8 EMI/EMC 2 9 Self-tests 2 10 Design Assurance 2 11 Mitigation of Other Attacks 2 Physical Security The Aruba Controller is a scalable, multi-processor standalone network device and is enclosed in a robust steel housing. The switch enclosure is resistant to probing and is opaque within the visible spectrum. The enclosure of the switch has been designed to satisfy FIPS 140-2 Level 2 physical security requirements. For the Aruba 6000-400 the left, top, right, and bottom surfaces are irremovable. The rear panel can be removed by unscrewing fifteen screws. The switch has a number of components at front side, including four slots for supervisor and line cards, one fan tray, and three power supplies. Each of the components is attached with two screws. For the Aruba 3000-series the left, right, front, rear, and bottom surfaces are irremovable. The top panel can be removed by unscrewing two screws. A metallic opaque shield is installed at the factory during manufacturing and can not be removed by the User. For physical security, the Aruba 6000-400 chassis requires Tamper-Evident Labels (TELs) to allow the detection of the opening of the chassis covers; the removal or replacement of any module or cover plate, and to block the Serial console port. The Aruba 3000-series Controllers require Tamper-Evident Labels (TELs) to allow the detection of the opening of the chassis cover and to block the Serial console port. To protect the Aruba 3000 and 6000/M3 Controllers from any tampering with the product, TELs should be applied by the Crypto Officer as covered under “ T amper-Evident Labels ” on page 33. Operational Environment The operational environment is non-modifiable. The control plane Operating System (OS) is Linux, a real-time, multi-threaded operating system that supports memory protection between processes. Access to the underlying Linux implementation is not provided directly. Only Aruba Networks provided interfaces are used, and the CLI is a restricted command set. Logical Interfaces All of these physical interfaces are separated into logical interfaces defined by FIPS 140-2, as described in the following table. Table 4 FIPS 140-2 Logical Interfaces FIPS 140-2 Logical Interface Module Physical Interface Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |15     Table 4 FIPS 140-2 Logical Interfaces Data Input Interface 10/100 Mbps Ethernet port 10/100/1000 Mbps Ethernet ports Data Output Interface 10/100 Mbps Ethernet port 10/100/1000 Mbps Ethernet ports Control Input Interface Power switch (Aruba 6000 only) Reset button (Aruba 6000 only) 10/100 Mbps Ethernet port 10/100/1000 Mbps Ethernet ports Serial console port (disabled) Status Output Interface 10/100 Mbps Ethernet port 10/100/1000 Mbps Ethernet ports LEDs Serial console port (disabled) Power Interface Power Supply POE (Aruba 6000 only) 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. • Control input consists of manual control inputs for power and reset through the power and reset switch. It also consists of all of the data that is entered into the switch while using the management interfaces. • Status output consists of the status indicators displayed through the LEDs, the status data that is output from the switch while using the management interfaces, and the log file. • LEDs indicate the physical state of the module, such as power-up (or rebooting), utilization level, activation state (including fan, ports, and power). The log file records the results of self-tests, configuration errors, and monitoring data. • A power supply is used to connect the electric power cable. Operating power is also provided (Aruba 6000 only) to a compatible Power Over Ethernet (POE) device when connected. The power is provided through the connected Ethernet cable. Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 16|       The switch distinguishes between different forms of data, control, and status traffic over the network ports by analyzing the packets header information and contents. Roles and Services The Aruba Controller supports role-based authentication. There are two roles in the switch (as required by FIPS 140-2 Level 2) that operators may assume: a Crypto Officer role and a User role. The Administrator maps to the Crypto- Officer role and the client Users map to the User role. Crypto Officer Role The Crypto Officer role has the ability to configure, manage, and monitor the switch. Three management interfaces can be used for this purpose: • CLI The Crypto Officer can use the CLI to perform non-security-sensitive and security-sensitive monitoring and configuration. The CLI can be accessed remotely by using the SSHv2 secured management session over the Ethernet ports or locally over the serial port. In FIPS mode, the serial port is disabled. • Web Interface The Crypto Officer can use the Web Interface as an alternative to the CLI. The Web Interface provides a highly intuitive, graphical interface for a comprehensive set of switch management tools. The Web Interface can be accessed from a TLS-enabled Web browser using HTTPS (HTTP with Secure Socket Layer) on logical port 4343. • Bootrom Monitor Mode In Bootrom monitor mode, the Crypto Officer can reboot, update the Bootrom, issue file system-related commands, modify network parameters, and issue various show commands. The Crypto Officer can only enter this mode by pressing any key during the first four seconds of initialization. Bootrom Monitor Mode is disabled in FIPS mode. The Crypto Officer can also use SNMPv1/2c/3 to remotely perform non-security- sensitive monitoring and use 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 Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |17     Table 5 Crypto-Officer Services Provide authenticated and SSH key agreement SSH outputs and Diffie-Hellman key pair SSH v2.0 encrypted remote management parameters, SSH data (read/ write access), sessions while using the CLI inputs, and data session key for SSH (read/write access), RNG keys (read access); Crypto Officer's password (read access) IKEv1/IKEv2- Provide authenticated and IKEv1/IKEv2 inputs and IKEv1/IKEv2 RSA or ECDSA key IPSec encrypted remote management data; IPSec inputs, outputs, status, and pair for IKEv1/IKEv2 sessions to access the CLI commands, and data data; IPSec (read access), Diffie- functionality outputs, status, and Hellman or Elliptic data curve Diffie-Hellman key pair for IKEv1/IKEv2 (read/write access), pre- shared keys for IKEv1/IKEv2 (read access); Session keys for IPSec (read/write access) Configuring Create management Users and Commands and Status of Crypto Officer's Network set their password and privilege configuration data commands and password for CLI Management level; configure the SNMP agent configuration data (read/write access) Configuring the Define the platform subsystem Commands and Status of None module Platform firmware of the module by configuration data commands and entering Bootrom Monitor Mode, configuration data File System, fault report, message logging, and other platform related commands Configuring Define synchronization features Commands and Status of None Hardware for module configuration data commands and Controllers configuration data Configuring the Commands and Status of Set IP functionality None Internet Protocol configuration data commands and configuration data Configuring Configure QOS values for module Commands and Status of None Quality of Service configuration data commands and (QoS) configuration data Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 18|       Table 5 Crypto-Officer Services Configuring the Configure Public Key Commands and Status of RSA and ECDSA keys VPN Infrastructure (PKI); configure the configuration data commands and pair (read/write Internet Key Exchange configuration data access), Pre-shared (IKEv1/IKEv2) Security Protocol; key (read/write access) configure the IPSec protocol Configure DHCP on Commands and Status of Configuring DHCP None module configuration data commands and configuration data Configuring Define security features for Commands and Status of AAA User password Security module, including Access List, configuration data commands and (read/write access), Authentication, Authorization and configuration data RADIUS password Accounting (AAA), and firewall (read/ write access) functionality Secure browser connection over TLS inputs, commands, TLS outputs, RSA key pair for TLS; HTTPS over TLS Transport Layer Security acting and data status, and data TLS Session Key as a Crypto Officer service (web management interface) Cryptographic officer may use Commands and Status of Status Function None CLI "show" commands or view configuration data commands and WebUI via TLS to view the switch configurations configuration, routing tables, and active sessions; view health, temperature, memory status, voltage, and packet statistics; review accounting logs, and view physical interface status IPSec tunnel Provided authenticated/encrypted IKEv1/IKEv2 inputs and IKEv1/IKEv2 Preshared key/RSA establishment for channel to RADIUS server data; IPSec inputs, outputs, status, and private key for RADIUS commands, and data data; IPSec IKEv1/IKEv2 (read protection outputs, status, and access), Diffie-Hellman data and Elliptic curve Diffie- Hellman key pair for IKEv1/IKEv2 (read/write access), Session keys for IPSec (read/write access) Run Power On Self-Tests and Error messages Self-test None None Conditional Tests logged if a failure occurs Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |19     Table 5 Crypto-Officer Services Configuring Configure bypass operation on Commands and Status of None Bypass Operation the module configuration data commands and configuration data Updating Commands and Status of Updating firmware on the module None Firmware configuration data commands and configuration data Configuring Online Configuring OCSP responder OCSP inputs, OCSP outputs, RSA/ECDSA key pair Certificate Status functionality commands, and data status, and data for signing OCSP Protocol (OCSP) responses Responder Configuring Configuring Control Plane Commands and Status of RSA private key for Control Plane Security mode to protect configuration data, commands, IKEv1/IKEv2 and Security (CPSec) communication with APs using IKEv1/IKEv2 inputs and IKEv1/IKEv2 certificate signing (read IPSec and issue self signed data; IPSec inputs, outputs, status, and access), Diffie-Hellman certificates to APs commands, and data data; IPSec key pair for outputs, status, and IKEv1/IKEv2 data and (read/write access), configuration data, Session keys for IPSec self signed (read/write access) certificates User Role The User role can access the switch’s IPSec and IKEv1/IKEv2 services. Service descriptions and inputs/outputs are listed in the following table: Table 6 User Service Service Description Input Output CSP Access Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 20|       IKEv1/IKEv2- Access the module's IPSec IPSec inputs, IPSec outputs, RSA and ECDSA key IPSec services in order to secure commands, and data status, and data pair for IKEv1/IKEv2 network traffic (read access); Diffie- Hellman and Elliptic curve Diffie-Hellman key pair for IKEv1/IKEv2 (read and write access); pre-shared keys for IKEv1/IKEv2 (read access) Access the module’s TLS TLS inputs, commands, TLS outputs, RSA key pair for TLS; HTTPS over TLS services in order to secure and data status, and data TLS Session Key network traffic EAP-TLS EAP-TLS inputs, EAP-TLS outputs, EAP-TLS RSA private Provide EAP-TLS termination termination commands and data status and data key (read) EAP-TLS ECDSA private key (read) 802.11i Shared Access the module’s 802.11i 802.11i inputs, 802.11i outputs, 802.11i Pre-Shared Key Key Mode services in order to secure commands and data status and data (read) network traffic 802.11i Session key (read/write) 802.11i with EAP- Access the module’s 802.11i 802.11i inputs, 802.11i outputs, EAP-TLS RSA private TLS services in order to secure commands and data status, and data key (read) network traffic EAP-TLS ECDSA private key (read) 802.11i Pair-Wise Master Key (read/write) 802.11i Session key (read/write) Data link (Layer 2) Access the module’s Layer 2 Data link encryption Data link Data link encryption AES Encryption encrypted tunnel services to inputs, commands and encryption, status, key (read) secure network traffic Data data and data link encryption inputs, commands and data Authentication Mechanisms The Aruba Controller supports role-based authentication. Role-based authentication is performed before the Crypto Officer enters privileged mode using admin password via Web Interface or SSH or by entering enable command and password in console. Role-based authentication is also performed for User authentication. Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |21     This includes password and RSA/ECDSA-based authentication mechanisms. The strength of each authentication mechanism is described below. Table 7 Estimated Strength of Authentication Mechanisms Authentication Type Role Strength Password-based authentication Passwords are required to be a minimum of six characters and a Crypto Officer (CLI and Web Interface) maximum of 32. Numeric, alphabetic (upper and lowercase), and keyboard and extended characters can be used, which gives a total of 95 characters to choose from. Therefore, the number of potential six- character passwords is 956 (735091890625). RSA-based authentication RSA signing and verification is used to authenticate to the module User (IKEv1/IKEv2) during IKEv1/IKEv2. This mechanism is as strong as the RSA algorithm using a 1024 or 2048 bit key pair. Pre-shared key-based Pre-shared keys must be at least six characters long and up to 64 User authentication (IKEv1/IKEv2) bytes long. Even if only uppercase letters were used without repetition for a six character pre-shared key, the probability of randomly guessing the correct sequence is one in 165,765,600. 1024 and 2048 bit RSA keys correspond to effective strength of 280 Pre-shared key based User and 2112 respectively. authentication (802.11i) 1024 and 2048 bit RSA keys correspond to effective strength of 280 EAP-TLS authentication User 112 and 2 respectively. ECDSA-based authentication ECDSA signing and verification is used to authenticate to the module User (IKEv1/IKEv2) during IKEv1/IKEv2. Both P-256 and P-384 keys are supported. ECDSA P-256 provides 128 bits of equivalent security, and P-384 provides 192 bits of equivalent security. Unauthenticated Services The Aruba Controller can perform SNMP management, VLAN, bridging, firewall, routing, and forwarding functionality without authentication. These services do not involve any cryptographic processing. Additional unauthenticated services include performance of the power-on self test and system status indication via LEDs. Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 22|       Cryptographic Key Management Implemented Algorithms FIPS-approved cryptographic algorithms have been implemented in firmware and hardware. The firmware supports the following cryptographic implementations. ArubaOS OpenSSL Module implements the following FIPS-approved algorithms: • AES (Cert. #1854) • Triple-DES (Cert. #1201) • SHS (Cert. #1631) • RNG (Cert. #972) • RSA (Cert. #937) • HMAC (Cert. #1101) • ECDSA (#258) ArubaOS Crypto Module implementation supports the following FIPS Approved Algorithms: • AES (Cert. #1850) • Triple-DES (Cert. #1198) • SHS (Cert. #1627) • RNG (Cert. #969) • RSA (Cert. #933) • HMAC (Cert. #1098) • ECDSA (Cert. #257) ArubaOS UBOOT Bootloader implements the following FIPS-approved algorithms: • RSA (Cert. #935) • SHS (Cert. #1629) The hardware supports the following cryptographic implementations. Hardware encryption acceleration is provided for bulk cryptographic operations for the following FIPS approved algorithms: • AES (Cert. #465) - CBC; 128,192,256 bits - CCM • Triple-DES (Cert. #482) - CBC; 192 bits (168 used)/1,2,3 keys keying option • SHS (Cert. #768) - SHA-1, SHA-256 - BYTE oriented • HMAC (Cert.#416) - HMAC-SHA-1, HMAC-SHA-256 Non-FIPS Approved Algorithms The cryptographic module implements the following non-approved algorithms that are not permitted for use in the FIPS 140-2 mode of operations: • DES • HMAC-MD5 • MD5 • RC4 Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |23     • NDRNG In addition, within the FIPS Approved mode of operation, the module supports the following allowed key establishment schemes: • Diffie-Hellman (key agreement; key establishment methodology provides 80 bits of encryption strength; non-compliant less than 80-bits of encryption strength) • EC Diffie-Hellman (key agreement; key establishment methodology provides between 128 and 192 bits of encryption strength) • RSA (key wrapping; key establishment methodology provides 80 bits of encryption strength) Critical Security Parameters The following are the Critical Security Parameters (CSPs) used in the switch. Table 8 CSPs Used in Aruba Controllers Storage and CSPs CSPs type Generation Use Zeroization Key Encryption Key Triple-DES 168-bit Stored in Flash and Encrypts IKEv1/IKEv2 Pre- Hard Coded (KEK) key zeroized by using the CLI shared key, RADIUS server command wipe out flash shared secret, RSA private key, ECDSA private key, 802.11i pre-shared key and Passwords. IKEv1/IKEv2 Pre- 64 character pre- Stored encrypted in Flash User and module CO configured shared key shared key with the KEK. Zeroized by authentication during IKEv1, changing (updating) the IKEv2 pre-shared key through the User interface. RADIUS server 6-128 character Stored encrypted in Flash Module and RADIUS server CO configured shared secret shared secret with the KEK. Zeroized by authentication changing (updating) the pre-shared key through the User interface. 6-64 character Store in ciphertext in Enable secret CO configured Administrator authentication password flash. Zeroized by changing (updating) through the user interface. Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 24|       Table 8 CSPs Used in Aruba Controllers IPSec session 168-bit Triple-DES Established during Stored in plaintext in Secure IPSec traffic encryption keys or 128/192/256-bit the Diffie-Hellman volatile memory. Zeroized AES-CBC or key agreement when the session is 128/256-bit AES- closed. GCM keys IPSec session Established during Stored in plaintext in HMAC SHA-1 key User authentication authentication keys the Diffie-Hellman volatile memory. Zeroized key agreement when the session is closed. SSH Diffie-Hellman 128-octet Established during Stored in plain text in Key agreement in SSH shared secret intermediate value the SSH Diffie- volatile memory, Zeroized used for key Hellman key when session is closed. derivation agreement IKEv1/IKEv2 Diffie- 768/1024-bit Generated internally Stored in the volatile Used in establishing the Hellman private key (MODP group) or during IKEv1/IKEv2 memory. Zeroized after session key for an IPSec 256/384-bit (Elliptic negotiations the session is closed. session curve group) Diffie- Hellman private key. Note: Key size 768 bits is not allowed in FIPS mode. IKEv1/IKEv2 Diffie- 128 octet or 32/48 Established during Stored in plaintext in Key agreement in IKEv1/IKEv2 Hellman shared octet (Elliptic curve the Diffie-Hellman volatile memory. Zeroized secret Diffie Hellman) Key Agreement when session is closed. intermediate value used for cryptographic key derivation IKEv1/IKEv2 160-bit HMAC- Established as a Stored in plaintext in IKEv1/IKEv2 payload integrity session SHA1or 256 byte result of Diffie- volatile memory. Zeroized verification authentication key HMAC-SHA-256- Hellman key when session is closed. 128 or 384 byte agreement. HMAC-SHA-384- 192 key IKEv1/IKEv2 168-bit Triple-DES Established as a Stored in plaintext in IKEv1/IKEv2 payload session encryption or 128/192/256-bit result of Diffie- volatile memory. Zeroized encryption key AES-CBC key Hellman key when session is closed. agreement. 168-bit Triple-DES Established during Stored in plaintext in SSH session keys Secure SSH traffic or 128/192/256-bit the SSH key volatile memory. Zeroized AES keys exchange using the when the session is Diffie-Hellman key closed. agreement Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |25     Table 8 CSPs Used in Aruba Controllers SSH session 160-bit HMAC- Established during Stored in plaintext in Secure SSH traffic authentication key SHA-1 the SSH key volatile memory. Zeroized exchange using the when the session is Diffie-Hellman key closed. agreement SSH Diffie-Hellman 768/1024-bit Diffie- Generated internally Stored in the volatile Used in establishing the Private Key Hellman private during the SSH memory. Zeroized after session key for an SSH key. Note: Key size session negotiations the session is closed. session. 768 bits is not allowed in FIPS mode. TLS pre-master Stored in plaintext in 48 byte secret Externally generated Key agreement during TLS secret volatile memory. Zeroized when the session is closed. TLS session Generated in the Stored in plaintext in Key agreement during 802.1x AES 128, 192, 256 encryption key module volatile memory. Zeroized connection when the session is closed. TLS session 160-bit HMAC- Generated in the Stored in plaintext in Key agreement during 802.1x authentication key SHA1 key module volatile memory. Zeroized connection when the session is closed. RSA 1024/2048 bit Generated in the Stored in flash memory Used by TLS and EAP- RSA Private Key key module encrypted with KEK. TLS/PEAP protocols during the Zeroized by the CO handshake, used for signing command write erase all. OCSP responses, and used by IKEv1/IKEv2 for device authentication and for signing certificates ECDSA suite B P- Generated in the Stored in flash memory Used by TLS and EAP- ECDSA Private Key 256 and P-384 module encrypted with KEK. TLS/PEAP protocols during the curves Zeroized by the CO handshake. command write erase all. Intermediate 160- Established during Stored in plaintext in skeyid Key agreement in IKEv1/IKEv2 bit/256-byte/384- the Diffie-Hellman volatile memory. Zeroized byte value used in Key Agreement when session is closed. key derivation Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 26|       Table 8 CSPs Used in Aruba Controllers Intermediate 160- Established during Stored in plaintext in skeyid_d Key agreement in IKEv1/IKEv2 bit/256-byte/384- the Diffie-Hellman volatile memory. Zeroized byte value used in Key Agreement when session is closed. key derivation 802.11i Pre-Shared 802.11i pre-shared CO configured Stored in flash memory Used by the 802.11i protocol Key (PSK) secret key (256-bit) encrypted with KEK. Zeroized by the CO command write erase all. 802.11i Pair-Wise 802.11i secret key Derived during the Stored in the volatile Used by the 802.11i protocol Master key (PMK) (256-bit) EAP-TLS/PEAP memory. Zeroized on handshake reboot. AES-CCM key Derived from 802.11 Stored in plaintext in 802.11i session key Used for 802.11i encryption (128 bit), AES- PMK volatile memory. Zeroized GCM key on reboot. (128/256-bit) Data link (Layer 2) Derived during the Stored in plaintext in Used to encrypt tunneled Layer AES key (256 bit) encryption key EAP-TLS handshake volatile memory. Zeroized 2 frames on reboot. Data link (Layer 2) HMAC-SHA1 key Derived during EAP- Stored in plaintext in Used to integrity-protect integrity key (160-bit) TLS handshake volatile memory. Zeroized tunneled Layer 2 frames storage and on reboot. zeroization: Stored in plaintext in volatile memory 6-character Stored encrypted in Flash Authentication for accessing Passwords CO configured password with KEK. Zeroized by the management interfaces, either deleting the RADIUS authentication password configuration file or by overwriting the password with a new one. ArubaOS OpenSSL Derived using NON- Stored in plaintext in Seed (16 bytes) Seed ANSI X9.31 RNG RNG Seed for FIPS FIPS approved HW volatile memory only. compliant ANSI RNG (/dev/urandom) Zeroized on reboot. X9.31, Appendix A2.4 using AES-128 key algorithm Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |27     Table 8 CSPs Used in Aruba Controllers ArubaOS OpenSSL Seed key (16 Derived using NON- Stored in plaintext in Seed ANSI X9.31 RNG RNG Seed key for bytes, AES-128 FIPS approved HW volatile memory only. FIPS compliant key algorithm) RNG (/dev/urandom) Zeroized on reboot. ANSI X9.31, Appendix A2.4 using AES-128 key algorithm ArubaOS Derived using NON- Stored in plaintext in Seed 186-2 General purpose Seed (64 bytes) cryptographic FIPS approved HW volatile memory. Zeroized (x-change Notice); SHA-1 RNG Module RNG seed RNG (/dev/urandom) on reboot. for FIPS compliant 186-2 General purpose (x-change Notice); SHA-1 RNG ArubaOS Seed key (64 Derived using NON- Stored in plaintext in Seed 186-2 General purpose cryptographic bytes) FIPS approved HW volatile memory. Zeroized (x-change Notice); SHA-1 RNG Module RNG seed RNG (/dev/urandom) on reboot. key for FIPS compliant 186-2 General purpose (x- change Notice); SHA-1 RNG Self-Tests The Aruba Controller performs both power-up and conditional self-tests. In the event any self-test fails, the switch will enter an error state, log the error, and reboot automatically. The following self-tests are performed: ArubaOS OpenSSL Module: • AES KAT • Triple-DES KAT • RNG KAT • RSA KAT • ECDSA (sign/verify) • SHA (SHA1, SHA256 and SHA384) KAT • HMAC (HMAC-SHA1, HMAC-SHA256 and HMAC-SHA384) KAT ArubaOS Cryptographic Module • AES KAT • Triple-DES KAT • SHA (SHA1, SHA256, SHA384 and SHA512) KAT • HMAC (HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512) KAT • RSA (sign/verify) Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 28|       • ECDSA (sign/verify) • FIPS 186-2 RNG KAT ArubaOS Uboot BootLoader Module Firmware Integrity Test: RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA-1 Aruba Hardware Known Answer Tests Revision B2: • AES KAT • AES-CCM KAT • Triple DES KAT • HMAC (HMAC-SHA1, HMAC-SHA256) KAT Following Conditional Self-tests are performed in the switch: ArubaOS OpenSSL Module • Bypass Test (Wired Bypass Test and Wireless Bypass Test) • CRNG Test on Approved RNG • ECDSA Pairwise Consistency Test • RSA Pairwise Consistency Test • Firmware Load Test - RSA PKCS#1 v1.5 (2048 bits) signature verification Aruba OS Crypto Module • CRNG Test on Approved RNG • ECDSA Pairwise Consistency Test • RSA Pairwise Consistency Test Conditional Tests on Hardware: • CRNG Test on non-Approved RNGs Self-test results are logged in a log file. Upon successful completion of the power-up self tests, the module logs a KATS: passed message into a log file. Confirm the file update by checking the associated time of the file. In the event of a hardware KATs failure, the log file records one of the following messages depending on the algorithm being validated: • AES256 HMAC-SHA1 hash failed • AES256 Encrypt failed • AES256 Decrypt Failed • 3DES HMAC-SHA1 hash failed • 3DES Encrypt failed • 3DES Decrypt Failed • DES HMAC-SHA1 hash failed • DES Encrypt failed • DES Decrypt Failed • HW KAT test failed for AESCCM CTR. Rebooting • AESCCM Encrypt Failed This text is followed by this message: The POST Test failed!!!! Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |29     Rebooting… Alternating Bypass State The controller implements an alternating bypass state when: • a port is configured in trusted mode to provide unauthenticated services • a configuration provides wireless access without encryption The alternating bypass status can be identified by retrieving the port configuration or the wireless network configuration. Mitigation of Other Attacks ArubaOS includes two modules that provide protection from attacks. These are: • XSec • Wireless Intrusion Protection XSec xSec is a highly secure data link layer (Layer 2) protocol that provides a unified framework for securing all wired and wireless connections using strong encryption and authentication. xSec provides greater security than Layer 3 encryption technologies through the use of FIPS-validated encryption algorithms (AES-CBC-256 with HMAC-SHA1) to secure Layer 2 traffic, as well as the encryption of Layer 2 header information including MAC addresses. xSec was jointly developed by Aruba Networks and Funk Software. Many government agencies and commercial entities that transmit highly sensitive information over wireless networks mandate that strong Layer 2 encryption technologies be deployed to ensure absolute data privacy. U.S. DoD Directive 8100.2 requires that all data transmitted using commercial wireless devices be encrypted at Layer 2 or Layer 3. The U.S. Navy and Army are requiring Layer 2 encryption, and cryptographic engines used for all sensitive government communications must be validated as meeting FIPS 140-2 requirements. xSec has been designed to address this requirement and to provide a number of additional benefits. Wireless Intrusion Detection Aruba’s Wireless Intrusion Protection (WIP) module eliminates the need for a separate system of RF sensors and security appliances. The WIP module provides extraordinary capabilities to Aruba’s enterprise mobility system, giving administrators visibility into the network, along with the power to thwart malicious wireless attacks, impersonations and unauthorized intrusions. Wireless intrusion detection is only the first step in securing the corporate environment from unwanted wireless access. Without adequate measures to quickly shut down intrusions, detection is almost worthless. Without accurate classification of APs and stations (e.g., valid, rogue, or neighbor), providing an automated response to possible intrusion is impossible. Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 30|       Aruba access points constantly scan all channels of the RF spectrum, capturing all 802.11 traffic and locally examining the captured data. Only policy violations are sent to the central controller to ensure minimal impact on wired network performance. While scanning the environment, the Aruba system learns about all wireless APs and stations and classifies these devices based on traffic flows seen on the wire and in the air. This traffic is collected and correlated on the controller. Aruba’s WIP module provides both detection and prevention capabilities. Users and devices are detected and classified so administrators can react to both unintentional and malicious WLAN access. No other system on the market provides such capabilities. Unique Station and User Classification Aruba’s patent-pending classification system automatically identifies and classifies all APs and stations connected to the network. The system works by comparing traffic seen in the air with traffic seen on the wire. When a match is found, it is known with certainty that the device belongs to the local network rather than a neighboring network. This avoids false alarms for the administrator, because only true rogue devices are classified as such. Detecting and Disabling Rogue APs Aruba’s classification algorithms allow the system to accurately determine who is a threat and who is not. Once classified as rogue, these APs can be automatically disabled. Administrators are also notified of the presence of rogue devices, along with their precise physical location on a floor plan, so that they may be removed from the network. Denial of Service and Impersonation Protection Wireless networks, by their nature, make an attractive target for denial of service attacks. Such attacks include software that floods the network with association requests, attacks that make a laptop look like thousands of APs, and deauthentication floods. Aruba controllers equipped with the Aruba WIP module maintain signatures of many different wireless attacks and are able to block them so service is not disrupted. Advanced Denial of Service (DoS) protection keeps enterprises safe against a variety of wireless attacks, including association and de-authentication floods, honeypots and AP and station impersonations. Based on location signatures and client classification, Aruba access points will drop illegal requests and generate alerts to notify administrators of the attack. Man-in-the-Middle Protection One of the common attacks possible in wireless networks is the “ man-in-the- middle ” attack. During a man-in-the-middle attack, a hacker masquerades as a legitimate AP. Then, acting as a relay point, this man-in-the-middle fools users and other APs into sending data through the unauthorized device. An Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |31     attacker can then modify or corrupt data or conduct password-cracking routines. Aruba access points monitor the air to detect other wireless stations masquerading as valid APs. When such masquerading is detected, appropriate defense mechanisms are put into place. Aruba controllers also track unique “ s ignatures ” for each wireless client in the network. If a new station is introduced claiming to be a particular client, but without the proper signature, a station impersonation attack is detected. Policy Definition and Enforcement Aruba WIP provides a number of policies that can be configured to take automatic action when a policy is violated. Examples of wireless policies include weak WEP implementation detection, AP misconfiguration protection, ad- hoc network detection and protection, unauthorized NIC type detection, wireless bridge detection and more. Using Wireless to Protect your Wired Network Even if wireless LANs are not sanctioned at this time, no security conscious company can afford to do nothing. Aruba’s WIP will keep wireless traffic from working its way into the wired network through rogue APs unknowingly attached to a network port. With Aruba’s mobility system equipped with WIP, the enterprise network is protected against wireless security holes. And when the enterprise is ready to deploy wireless LANs, the Aruba system can be easily reconfigured to provide a scalable and secure wireless LAN infrastructure. Using Wireless to Protect your Existing Wireless Network Aruba’s mobility system with WIP delivers the detection and protection necessary to keep your existing wireless network safe from undesirable wireless access. ArubaOS WIP complements and enhances any existing WLAN deployment, including Cisco deployments, by providing advanced RF security and control features not found in first-generation wireless products.         Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 32|           Installing the Controller This chapter covers the physical installation of the Aruba 3000 and 6000/M3 Controllers with FIPS 140-2 Level 2 validation. The Crypto Officer is responsible for ensuring that the following procedures are used to place the switch in a FIPS-approved mode of operation. This chapter covers the following installation topics: • Precautions to be observed during installation • Requirements for the switch components and rack mounting gear • Selecting a proper environment for the switch • Mounting the switch in a rack • Connecting power to the switch Pre-Installation Checklist You will need the following during installation: • Aruba 3000 and 6000/M3 Controller components. • Aruba 3000 and 6000/M3 rack mounting kit. • Phillips or cross-head screwdriver. • 19-inch equipment rack, or equivalent. • 3U rack space for the Aruba 6000-400 and 1U rack space for the Aruba 3000-Series with 10 cm (4 inches) clearance to the left, right, front, and rear of the rack. • Another person to help position the switch. • Aruba power cord for each power supply, rated to at least 10 A with IEC320 connector. • Adequate power supplies and electrical power. • Cool, non-condensing air 0 to 40 ºC (32 to 104 ºF). May require air conditioning. • Management Station (PC) with 10/100 Mbps Ethernet port and SSH software. • A 4- or 8-conductor Category 5 UTP Ethernet cable. Precautions • Installation should be performed only by a trained technician. • Dangerous voltage in excess of 240 VAC is always present while the Aruba power supply is plugged into an electrical outlet. Remove all rings, jewelry, and other potentially conductive material before working with this product. • Never insert foreign objects into the chassis, the power supply, or any other component, even when the power supplies have been turned off, unplugged, or removed. • Main power is fully disconnected from the switch only by unplugging all power cords from their power outlets. For safety reasons, make sure the power outlets and plugs are within easy reach of the operator. • Do not handle electrical cables that are not insulated. This includes any network cables. • Keep water and other fluids away from the product. • Comply with electrical grounding standards during all phases of installation and operation of the product. Do not allow the switch 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 remo I oval of the chassis or any mod e dule must be performmed in a s static-freee environment. The pro e oper use of anti-sta atic body s straps and mats is s d strongly recommended. r • Keep modules in anti K i-static pa ackaging w when not in nstalled i the chas in ssis. • Do D not ship or store this prod p e duct near strong ele ectromagneetic, elect trostatic, magnetic or o radioactive fieldds. • Do D not disassemble chassis or modules. They have no intern c nal user-se erviceable parts. e When service or repa W air is need ded, conta act Aruba N Networks. Prod duct Exam mination The units are shipped to the Cryp t pto Office in facto er ory-sealed boxes usi d ing truste ed comm mercial carrier ship pping compa anies. The Crypto Of e fficer sho ould examin the car ne rton for evid dence of tampering. Tamper-evidence inc cludes tear rs, scratc ches, and o other irre egularities s in t the packaging. Package Cont tents The product carton shou uld include the foll e lowing: • Aruba 3000 a and 6000/M3 Controll ler • Rack mountin kit ng • Aruba User D Documentation CD • Tamper-Evide ent Labels Minimum Con nfiguration for the Aruba 6000-4 400 The Aruba 6000-400 cont troller cha assis must include t t the follow wing basic component ts: • One modular switch chassis • One fan tray y • One Aruba M3 3mk1-S-F1 card in sl lot 0 • Power Supply y The number and type of power s e t supplies require depends on the number of line ed n f card installed in the chassis (refer to the Aruba 6000 Mobility Controller ds t y Inst tallation Guide) It is the Crypto Office's resp ). ponsibility to ins stall all require ed pow supplies du wer uring module se etup phase. The switch is shipp ped with all requ uired mod dules ins stalled. The Aruba 3000 series do not ha minimum c e s ave configurations, as they are fixe ed con nfiguration chas ssis. Aruba 30 and 6000/M3 |FIPS 140-2 Le 000 3 evel 2 Release Supplement 34|       Tam mper-Evident Labels Afte testing, the Cryp er pto Officer must app ply Tamper-Evident L Labels (TEL Ls) to the switch. e When applied p n properly, the TELs a allow the Crypto Off ficer to d detect the opening o the of chas ssis cover, the remo oval or rep placement of modules or cover plates, o physica access s r or al to r restricted ports. Ve endor provides FIPS 140 design nated TELs which hav met the physical s ve e secu urity testing requir rements for tamper e evident lab bels under the FIPS 140-2 Sta r andard. TELs are not endorsed by the Cryp s b ptographic Module Va c alidation Program (C CMVP). The tamper-evident labels shall be installed for the module to operate in a F e r o FIPS App proved mode of operation. Aruba Provides do ouble the required amount of TELs. If a cust tomer requires replacement TELs please call customer suppo and Aruba w provide the TELs s, ort will (Pa # 4010061-0 art 01). The Crypto officer shall be respo e r onsible for keep ping the extra T TELs at a safe loca ation and manaaging the use o the TELs. of Rea ading TELs s Once applied, the TELs included w e with the s switch cann not be sur rreptitious sly broken removed, n, or r reapplied w without an obvious change in appearance n e: Figure 3 Tamper- -Evident Labe els Each TELs also has a un h nique seria number to prevent replacem al t ment with s similar la abels. Req quired TEL Locations s The Aruba 6000-400 controll ler chass sis requi ires a mi inimum of 11 TELs to be f s applied as follows: 5   Aruba 3 3000 and 6000/M |FIPS 140-2 L M3 Level 2 Release S Supplement |35   Figu 4 Required TELs for the Aruba 6000 Controller C ure d e 0 Chassis To D Detect Openi the Chas ing ssis Cover 1. 1 Spanning the left side and rear of t t the chassis s 2. 2 Spanning the righ side and rear of the chassi ht d is To D Detect the Re emoval of Any Module o Cover Plate or 3. 3 Spanning the Slot 2 facepla t ate or bla ank and the top of t e the chassis s 4. 4 Spanning the Slot 3 facepla t ate or bla ank and the top of t e the chassis s 5. 5 Spanning the Slot 0 facepla t ate or bla ank and the Slot 2 f e faceplate o blank or 6. 6 Spanning the Slot 1 facepla t ate or bla ank and the Slot 3 f e faceplate o blank or 7. 7 Spanning the fan tray facepplate and the bottom of the c m chassis 8. 8 Spanning the PS1 handle (or blank faaceplate) a and the bo ottom of th chassis he s 9. 9 Spanning the PS2 handle (or blank faaceplate) a and the bo ottom of th chassis he s 10 0.Spanning the PS3 handle (or blank fac g h r ceplate) and the bot ttom of the chassis To D Detect Acces to Restric ss cted Ports 11.Spanning the Seri 1 ial port on the M3 n The Aruba 3000 series Contr roller requir a minimum of 3 TELs to be applie as follows re m s ed s: Figure 5 Required TELs for the Aruba 3000 d e 0-series Contr roller To D Detect Acces to Restric ss cted Port 1. 1 Spanning the Seri ial port To D Detect Openi the Chas ing ssis Cover 2. 2 Spanning the top of the faceplate an top of t nd the chassi is 3. 3 Spanning the back and top o the cha k of assis App plying TELs s The Crypto Officer shou uld employ TELs as f follows: • Be efore appl lying a TEL make su L, ure the tar rget surfaces are cl lean and dry. Aruba 30 and 6000/M3 |FIPS 140-2 Le 000 3 evel 2 Release Supplement 36|       • Do not cut, trim, punch, or otherwise alter the TEL. • Apply the wholly intact TEL firmly and completely to the target surfaces. • Ensure that TEL placement is not defeated by simultaneous removal of multiple modules. • Allow 24 hours for the TEL adhesive seal to completely cure. • Record the position and serial number of each applied TEL in a security log. Once the TELs are applied, the Crypto Officer (CO) should perform initial setup and configuration as described in the next chapter.     Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement |37           Ongoing Management  The Aruba 3000 and 6000/M3 Controllers meet FIPS 140-2 Level 2 requirements. The information below describes how to keep the switch in FIPS-approved mode of operation. The Crypto Officer must ensure that the switch is kept in a FIPS-approved mode of operation. Crypto Officer Management The Crypto Officer must ensure that the switch is always operating in a FIPS-approved mode of operation. This can be achieved by ensuring the following: • FIPS mode must be enabled on the switch before Users are permitted to use the switch (see “ Enabling FIPS Mode ” on page 37) • The admin role must be root. • Passwords must be at least six characters long. • VPN services can only be provided by IPsec or L2TP over IPsec. • Access to the switch Web Interface is permitted only using HTTPS over a TLS tunnel. Basic HTTP and HTTPS over SSL are not permitted. • Only SNMP read-only may be enabled. • Only FIPS-approved algorithms can be used for cryptographic services (such as HTTPS, L2, AES-CBC, SSH, and IKEv1/IKEv2-IPSec), which include AES, Triple-DES, SHA-1, HMAC SHA-1, and RSA signature and verification. • TFTP can only be used to load backup and restore files. These files are: Configuration files (system setup configuration), the WMS database (radio network configuration), and log files. (FTP and TFTP over IPsec can be used to transfer configuration files.) • The switch logs must be monitored. If a strange activity is found, the Crypto Officer should take the switch off line and investigate. • The Tamper-Evident Labels (TELs) must be regularly examined for signs of tampering. • When installing expansion or replacement modules for the Aruba 6000-400, use only FIPS- approved modules, replace TELs affected by the change, and record the reason for the change, along with the new TEL locations and serial numbers, in the security log. • The Crypto Officer shall not configure the Diffie-Hellman algorithm with 768-bits (Group 1) in FIPS mode for IKEv1/IKEv2-IPSec and SSH. User Guidance The User accesses the switch VPN functionality as an IPsec client. The user can also access the switch 802.11i functionality as an 802.11 client. Although outside the boundary of the switch, the User should be directed to be careful not to provide authentication information and session keys to others parties.       Setup and Configuration The Aruba 3000 and 6000/M3 Controllers meet FIPS 140-2 Level 2 requirements. The sections below describe how to place and keep the switch in FIPS-approved mode of operation. The Crypto Officer (CO) must ensure that the switch is kept in a FIPS-approved mode of operation. The switch can operate in two modes: the FIPS-approved mode, and the standard non-FIPS mode. By default, the switch operates in non-FIPS mode. Setting Up Your Controller To set up your controller: 1. Make sure that the controller is not connected to any device on your network. 2. Boot up the controller. 3. Connect your PC or workstation to a line port on the controller. For further details, see the ArubaOS 6.1 Quick Start Guide. Enabling FIPS Mode For FIPS compliance, users cannot be allowed to access the switch until the CO changes the mode of operation to FIPS mode. There are two ways to enable FIPS mode: • Use the WebUI • Use the Setup Wizard Enabling FIPS with the Setup Wizard The Setup Wizard allows you to configure access to the controller, install software licenses, and configure wireless local area networks (WLANs) for internal or guest users. The Setup Wizard is available the first time you connect to and log into the controller or whenever the controller is reset to its factory default configuration. After you complete the Setup Wizard, the controller reboots using the new configuration information you entered. For details on running the Setup Wizard, see the ArubaOS 6.1 Quick Start Guide. Enabling FIPS with the WebUI The default IP address of the controller is 172.16.0.254. When you connect a PC or workstation to a line port on the controller, you can connect to this IP address through a Web browser. The system must be configured to either obtain its IP address via DHCP or have a static IP address on the 172.16.0.0/24 subnetwork. To log in with the WebUI: 1. Open a Web browser and connect to http://172.16.0.254. 2. Log in. 3. Go to the Configuration > Network > Controller > System Settings page (the default page when you click the Configuration tab). 4. Click the FIPS Mode for Controller Enable checkbox. If you need to enable FIPS mode on a controller that is no longer in the factory default configuration, you can either: • Log in through the WebUI as described previously • Enable FIPS on the Configuration > Wizards > Controller Wizard page • ‘FIPS Enable’ is shown on SSH Command Line Interface (CLI) after issuing the command show fips. Disallowed FIPS Mode Configurations When you enable FIPS mode, the following configuration options are disallowed: • All WEP features • WPA • TKIP mixed mode • Any combination of DES, MD5, and PPTP   Aruba 3000 and 6000/M3 |FIPS 140-2 Level 2 Release Supplement 40|