1 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Aruba Virtual and Hardware Mobility
Master Appliances
with ArubaOS FIPS Firmware
Non-Proprietary Security Policy
FIPS 140-2 Level 1
Version 2.6
October 2023
Non-Proprietary
2 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Copyright
© 2023 Hewlett Packard Enterprise Company. Hewlett Packard Enterprise Company 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 Hewlett Packard Enterprise Company 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. 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. 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
6280 America Center Dr
San Jose, CA, USA 95002
Phone: 408.227.4500
Fax 408.227.4550
3 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Contents
Contents.....................................................................................................................................................................................................3
Preface.......................................................................................................................................................................................................5
1 Purpose of this Document .................................................................................................................................................................5
1.1 Related Documents ..................................................................................................................................................................5
1.2 Additional Product Information..................................................................................................................................................5
2 Overview............................................................................................................................................................................................6
2.1 Cryptographic Module Boundaries of Hardware Appliances.....................................................................................................7
2.2 Cryptographic Module Boundaries of Virtual Appliances..........................................................................................................8
2.3 Intended Level of Security ........................................................................................................................................................9
3 Physical Security ...............................................................................................................................................................................9
4 Operational Environment.................................................................................................................................................................10
5 Logical Interfaces ............................................................................................................................................................................10
6 Roles and Services..........................................................................................................................................................................11
6.1 Crypto Officer Role .................................................................................................................................................................11
6.2 User Role................................................................................................................................................................................16
6.3 Unauthenticated Services.......................................................................................................................................................16
6.4 Services Available in Non-FIPS Mode....................................................................................................................................16
6.5 Non-Approved Services Non-Approved in FIPS Mode...........................................................................................................16
6.6 Authentication Mechanisms....................................................................................................................................................17
6.7 Cryptographic Key Management ............................................................................................................................................18
6.7.1 FIPS Approved Algorithms................................................................................................................................................18
6.7.2 Non-FIPS Approved but Allowed Cryptographic Algorithms .............................................................................................24
6.7.3 Non-FIPS Approved Cryptographic Algorithms.................................................................................................................24
6.8 Critical Security Parameters ...................................................................................................................................................25
6.9 Self-Tests................................................................................................................................................................................33
7 Installing the Mobility Master Hardware Appliance..........................................................................................................................35
7.1 Pre-Installation Checklist ........................................................................................................................................................35
7.2 Precautions.............................................................................................................................................................................35
7.3 Product Examination...............................................................................................................................................................36
7.4 Package Contents...................................................................................................................................................................36
8 Installing the Mobility Master Virtual Appliance ...............................................................................................................................36
8.1 Pre-Installation Checklist ........................................................................................................................................................36
8.1.1 Product Examination.........................................................................................................................................................36
8.1.2 Package Contents.............................................................................................................................................................36
9 Ongoing Management.....................................................................................................................................................................37
Non-Proprietary
4 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
9.1 Crypto Officer Management....................................................................................................................................................37
9.2 User Guidance........................................................................................................................................................................37
9.3 Setup and Configuration.........................................................................................................................................................37
9.4 Setting Up Your Mobility Master .............................................................................................................................................37
9.5 Enabling FIPS Mode...............................................................................................................................................................38
9.5.1 Enabling FIPS Mode with the CLI .....................................................................................................................................38
9.6 Disallowed FIPS Mode Configurations ...................................................................................................................................38
9.7 Full Documentation.................................................................................................................................................................39
5 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Preface
This security policy document can be copied and distributed freely.
1 Purpose of this Document
This release supplement provides information regarding the Aruba Virtual and Hardware Mobility Master Appliances with ArubaOS
FIPS Firmware with FIPS 140-2 Level 1 validation from Aruba Networks. The material in this supplement modifies the general Aruba
hardware appliance, virtual appliance, 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 Virtual and Hardware Mobility
Master Appliances with ArubaOS FIPS Firmware. This security policy describes how the Aruba Virtual and Hardware Mobility Master
Appliances with ArubaOS FIPS Firmware meets the security requirements of FIPS 140-2 Level 1 and how to place and maintain the
Aruba Virtual and Hardware Mobility Master Appliances with ArubaOS FIPS Firmware in a secure FIPS 140-2 mode. This policy was
prepared as part of the FIPS 140-2 Level 1 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) website at:
https://csrc.nist.gov/projects/cryptographic-module-validation-program
In addition, in this document, the Aruba Virtual and Hardware Mobility Master Appliances with ArubaOS FIPS Firmware are referred to
as the appliance, module, MM, HMM, VMM, MM-1K, MM5K, MM-10K, MM-VA-50, MM-VA-500, MM-VA-1K, MM-VA-5K, or MM-VA-
10K.
1.1 Related Documents
The following items are part of the complete installation and operations documentation included with this product:
• Aruba Mobility Master Hardware Appliance Installation Guide
• ArubaOS 8.X.0.0 Virtual Appliance Installation Guide
• ArubaOS 8.X.0.0 User Guide
• ArubaOS 8.X.0.0 CLI Reference Guide
• ArubaOS 8.X.0.0 Getting Started Guide
• ArubaOS 8.X.0.0 Migration Guide
1.2 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:
https://csrc.nist.gov/projects/cryptographic-module-validation-program
Non-Proprietary
6 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
2 Overview
The Aruba Mobility Master is the next generation of appliances that can be either deployed on an x86-based hardware appliance or on
a hypervisor as a virtual appliance. The Mobility Master provides better user experience, flexible deployment, simplified operations and
enhanced performance. Existing Aruba customers can migrate their master controller configuration and licenses over to the Mobility
Master and start taking advantage of these unique capabilities.
Massive traffic is hitting the network from mobile devices, IoT and business critical applications. Users expect no interruption in their
mobile experience. Controller Clustering, Live upgrade, in-service upgrade as well as Multi OS support would drastically increase
availability of the network.
Controller Clustering provides the following benefits for a better user experience.
• Hitless failover – Users will not notice any issues in the rare event of a controller failure. Voice calls, video, data transfers
would all continue without noticeable impact. User session information is shared across controllers in the cluster to ensure
there is no single point of failure for any user.
• Automatic user load balancing – Users are distributed evenly across controllers to prevent congestion on a single controller.
This ensures a large amount of available throughput for each user even when massive crowds gather.
• Automatic AP load balancing – The access points automatically are load balanced across cluster of controller for better
resource utilization and high availability when controller goes down. AP load balancing is done in seamless fashion so users
are not affected.
• Seamless roaming – Users do not experience any delays while moving through a large campus while on mission critical
applications such as a Skype for Business call. All of the controllers in a cluster work together to manage the users. A user
can roam across 10,000 APs without ever getting a new IP address, re-authenticating, or losing firewall state information.
The module configurations validated during the cryptographic module testing included:
• The firmware version is ArubaOS 8.10.0.2-FIPS
Aruba's development processes are such that future releases under AOS 8.10 should be FIPS validate-able and meet the claims made
in this document. Only the versions that explicitly appear on the certificate, however, are formally validated. The CMVP makes no claim
as to the correct operation of the module or the security strengths of the generated keys when operating under a version that is not
listed on the validation certificate.
The tested platforms are:
• Aruba Mobility Master 1K – F1 Hardware Appliance with an Intel Xeon Silver with AES-NI (JZ396A)
• Aruba Mobility Master 5K – F1 Hardware Appliance with an Intel Xeon Silver with AES-NI (JZ397A)
• Aruba Mobility Master 10K – F1 Hardware Appliance with an Intel Xeon Silver with AES-NI (JZ398A)
• ESXi 6.5 running on HPE ProLiant ML110 Gen10 with an Intel Xeon Silver with AES-NI
• ESXi 6.5 running on HPE ProLiant ML110 Gen10 with an Intel Xeon Silver without AES-NI.
The virtual appliances included in this validation are:
• JZ106AAE Aruba MM-VA-50 Mobility Master Virtual Appliance with Support for up to 50 Devices E-LTU
• JY895AAE Aruba MM-VA-500 Mobility Master Virtual Appliance with Support for up to 500 Devices E-LTU
• JY896AAE Aruba MM-VA-1K Mobility Master Virtual Appliance with Support for up to 1,000 Devices E-LTU
• JY897AAE Aruba MM-VA-5K Mobility Master Virtual Appliance with Support for up to 5,000 Devices E-LTU
• JY898AAE Aruba MM-VA-10K Mobility Master Virtual Appliance with Support for up to 10,000 Devices E-LTU
7 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
The list of vendor affirmed devices for the virtual appliances are listed below. Aruba believes that all functionality claimed within this
Security Policy can be successfully met with these devices.
• HPE EdgeLine 20, Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
• DTECH M3-SE-SVR4, Intel(R) Xeon(R) CPU E3-1505M v6 @ 3.00GHz
• DTECH M3x, Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
• Klas Telecom TDC Blade, Intel® Xeon(R) CPU D-1541 @ 2.10GHz
• Klas Telecom VoyagerVMm, Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz
• PacStar PS451-4330 Series, Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
• PacStar PS451-1258 Series, Intel(R) Xeon(R) CPU E3-1258L v4 @ 1.80GHz
• IAS VPN Gateway Module NANO-VM, Intel(R) Atom(TM) E3900 CPU @ 1.60GHz
• IAS VPN Gateway Module Classic Plus, Intel(R) Core(TM) i7-6xxx CPU @ 3.40GHz
• Device running an equivalent Intel Atom, i5, i7, or Xeon processor on ESXi 6.5
The CMVP makes no claim as to the correct operation of the module or the security strengths of the generated keys when ported to an
operational environment which is not listed on the validation certificate.
2.1 Cryptographic Module Boundaries of Hardware Appliances
For FIPS 140-2 Level 1 validation, the Mobility Master Hardware appliance has been tested as a multi-chip standalone firmware
module. The logical cryptographic boundary is defined as the firmware image and bootloader. The physical boundary is the surface of
the computer chassis.
Figure 1 – Mobility Master Appliances
Figure 1 shows the front of the three Mobility Master Appliances (1K, 5K, 10K variants), and illustrates the following:
• Two 10GBASE-X (SFP+) ports
• One 1GBASE-T Management port
• One RJ-45 Console port (Disabled in FIPS mode via instruction in Section 9)
• USB Port
• Port LINK/ACT and status LEDs
• Front panel LEDs – Power, Status, Peered
Non-Proprietary
8 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Each Appliance has the following dimensions and weight:
• 4.4 cm (H) x 44.2 cm (W) x 40.1 cm (D) (1.73” x 17.40” x 15.79”)
• Weight: 7.2 kg (15.87 lbs)
For the FIPS 140-2 Level 1 validation, all three Hardware appliances were tested.
2.2 Cryptographic Module Boundaries of Virtual Appliances
For FIPS 140-2 Level 1 validation, the module has been tested as a multi-chip standalone firmware module. The logical cryptographic
boundary of the virtual Mobility Master is defined as the entirety of the OVA file installed on the hypervisor which contains the firmware
image (Aruba Networks Mobility Master Firmware shown below). The physical boundary is the surface of the computer chassis. For the
hardware Mobility Master, the below diagram is applicable but do note that the Virtual Host is not applicable to hardware models.
Figure 2: Functional Block Diagram of the System Component Stack
9 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
2.3 Intended Level of Security
The Mobility Master and associated modules are intended to meet overall FIPS 140-2 Level 1 requirements as shown in Table 1.
Table 1 Intended Level of Security
Section Section Title Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 2
4 Finite State Model 1
5 Physical Security 1
6 Operational Environment N/A
7 Cryptographic Key Management 1
8 EMI/EMC 1
9 Self-tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks N/A
Overall Overall module validation level 1
3 Physical Security
The Aruba Mobility Master Hardware appliance is a scalable, multi-processor standalone network device and is enclosed in a robust
housing. The enclosure of the module has been designed to satisfy FIPS 140-2 Level 1 physical security requirements.
The Aruba Mobility Master Virtual appliance must be run on a production grade platform (such as a standard commercially made PC,
laptop, server, etc.) to meet requirements from FIPS 140-2 level 1. The platforms used for the virtual appliances, as tested in this
validation, meet the requirements for Level 1 physical security requirements.
Non-Proprietary
10 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
4 Operational Environment
The operational environment of the Hardware appliance 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.
The module only allows the loading of trusted and verified firmware that is signed by Aruba. The hardware appliances used during
testing met Federal Communications Commission (FCC) FCC Electromagnetic Interference (EMI) and Electromagnetic Compatibility
(EMC) requirements for business use as defined by 47 Code of Federal Regulations, Part15, Subpart B, Class A.
The operational environment of the Virtual appliance is limited and non-modifiable. The module was tested on Intel Xeon Silver running
on ESXi 6.5. The platform used during testing met Federal Communications Commission (FCC) FCC Electromagnetic Interference
(EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined by 47 Code of Federal Regulations, Part15,
Subpart B, Class A.
5 Logical Interfaces
All of these physical interfaces are separated into logical interfaces defined by FIPS 140-2, as described in the following table.
Table 2 FIPS 140-2 Logical Interfaces
FIPS 140-2 Logical Interface Module Physical Interface
Data Input Interface • 10/100/1000 Ethernet Ports (HW)
• SFP/SFP+ Uplink Ports (HW)
• Virtual Ethernet Ports (Virtual)
Data Output Interface • 10/100/1000 Ethernet Ports (HW)
• SFP/SFP+ Uplink Ports (HW)
• Virtual Ethernet Ports (Virtual)
Control Input Interface • 10/100/1000 Ethernet Ports (HW)
• SFP/SFP+ Uplink Ports (HW)
• Virtual Ethernet Ports (Virtual)
Status Output Interface • 10/100/1000 Ethernet Ports (HW)
• SFP/SFP+ Uplink Ports (HW)
• Virtual Ethernet Ports (Virtual)
• LEDs (HW)
Power Interface • Power Supply (HW)
• Host Platform Power Supply (Virtual)
Data input and output, control input, status output, and power interfaces are defined as follows:
11 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
• 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 Mobility Master while using the management interfaces.
• Status output consists of the status indicators displayed through the LEDs, the status data that is output from the Mobility
Master 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.
The Mobility Master distinguishes between different forms of data, control, and status traffic over the network ports by analyzing the
packets header information and contents.
6 Roles and Services
The Aruba Mobility Master supports role-based authentication. There are two roles in the module (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. These clients are the Mobility Controllers which are managed by the Mobility Master. For additional non-
security-relevant services offered by the module, please refer to the ArubaOS User Guide listed in section 9
6.1 Crypto Officer Role
The Crypto Officer role has the ability to configure, manage, and monitor the managed controller. Three management interfaces can be
used for this purpose:
• SSHv2 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.
• 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 controller management tools. The Web Interface can be accessed from a TLS-enabled Web
browser using HTTPS (HTTP over TLS) on logical port 4343.
• SNMPv3
The Crypto Officer can also use SNMPv3 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.
Non-Proprietary
12 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Table 3 Crypto-Officer Services
Service Description Input Output
CSP/Algorithm Access
(see Table 9 below for details)
SSHv2 Provide authenticated and
encrypted remote management
sessions while using the CLI
SSHv2 key agreement
parameters, SSH
inputs, and data
SSHv2 outputs and
data
25, 26 (read/write/delete)
SNMPv3 Provides ability to query
management information
SNMPv3 requests SNMPv3
responses
31, 32, 33, 34, 35
(read/write/delete)
IKEv1/IKEv2-
IPSec
Access the module's IPSec
services in order to secure
network traffic
IKEv1/IKEv2 inputs and
data; IPSec inputs,
commands, and data
IKEv1/IKEv2
outputs, status, and
data; IPSec
outputs, status, and
data
17 (read)
5, 6, 7, 8, 9, 10
(read/write/delete)
18, 19, 20, 21, 22, 23, 24
(read/delete)
Configuring
Network
Management
Create management Users and
set their password and privilege
level; configure the SNMP agent
Commands and
configuration data
Status of
commands and
configuration data
31, 32, 34, 35 (read)
33 (delete)
Configuring the
module
Define synchronization features
for module
Commands and
configuration data
Status of
commands and
configuration data
None
Configuring
Internet Protocol
Set IP functionality Commands and
configuration data
Status of
commands and
configuration data
None
Configuring
Quality of Service
(QoS)
Configure QOS values for module Commands and
configuration data
Status of
commands and
configuration data
None
Configuring VPN Configure Public Key
Infrastructure (PKI); configure the
Internet Key Exchange
(IKEv1/IKEv2) Security Protocol;
configure the IPSec protocol
Commands and
configuration data
Status of
commands and
configuration data
17 (read)
13, 14, 15, 16 (read)
18, 19, 20, 21, 22, 23, 24
(delete)
Configuring
DHCP
Configure DHCP on module Commands and
configuration data
Status of
commands and
configuration data
None
13 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Service Description Input Output
CSP/Algorithm Access
(see Table 9 below for details)
Configuring
Security
Define security features for
module, including Access List,
Authentication, Authorization and
Accounting (AAA), and firewall
functionality
Commands and
configuration data
Status of
commands and
configuration data
11, 12 (read/write/delete)
Manage
Certificates
Install and delete X.509
certificates
Commands and
configuration data;
Certificates and keys
Status of
certificates,
commands, and
configuration
13, 14, 15,16 (write/delete)
NTP
Authentication
Service
Configure and connect to NTP
server using authentication key
Commands and data NTP output, status,
and data
37 (write/delete)
HTTP over TLS Secure browser connection over
Transport Layer Security acting
as a Crypto Officer service (web
management interface)
TLS inputs, commands,
and data
TLS outputs,
status, and data
5, 6, 7, 27, 28, 29 and 30
(read/write/delete)
3, 4 (read/write)
1, 2 (read)
SDN Controller The Software Defined Networking
(SDN) Controller provides a
networking infrastructure to build,
deliver, and manage features on
the managed devices via
separation of control-plane and
data-plane functions, centralized
manageability, and dynamic
programmability of managed
devices.
Configuration Data and
statistic collection
Status of
commands and
configuration data
None
Status Function Cryptographic officer may use
CLI "show" commands or view
WebUI via TLS to view the MM
configuration, routing tables,
controller configurations, and
active sessions; view health,
temperature, memory status,
voltage, and packet statistics;
review accounting logs, and view
physical interface status
Commands and
configuration data
Status of
commands and
configurations
None
Non-Proprietary
14 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Service Description Input Output
CSP/Algorithm Access
(see Table 9 below for details)
IPSec tunnel
establishment for
RADIUS
protection
Provided authenticated/encrypted
channel to RADIUS server
IKEv1/IKEv2 inputs and
data; IPSec inputs,
commands, and data
IKEv1/IKEv2
outputs, status, and
data; IPSec
outputs, status, and
data
11 and 17
(read/write/delete)
18, 19, 20, 21, 22, 23 and
24 (write/delete)
3, 4 (read/write)
1, 2 (read)
Self-Test Perform FIPS start-up tests on
demand
None Error messages
logged if a failure
occurs
None
Updating
Firmware
Updating firmware on the module.
Any firmware loaded into this
module that is not shown on the
module certificate is out of the
scope of this validation and
requires a separate FIPS 140-2
validation.
Commands and
configuration data
Status of
commands and
configuration data
36 (read)
Configuring
Online Certificate
Status Protocol
(OCSP)
Responder
Configuring OCSP responder
functionality
OCSP inputs,
commands, and data
OCSP outputs,
status, and data
27, 28, 29, 30 (read)
Configuring
Control Plane
Security (CPSec)
Configuring Control Plane
Security mode to protect
communication to other Mobility
Masters or Controllers using
IPSec with certificate
authentication. Hybrid CPsec
allows for the ability to enable or
disable independently for each
zone and allow zones to contain
different configurations. It can
interact with hardware and virtual
appliances through multizone
when CPsec is enabled.
Commands and
configuration data,
IKEv1/IKEv2 inputs and
data; IPSec inputs,
commands, and data
Status of
commands,
IKEv1/IKEv2
outputs, status, and
data; IPSec
outputs, status, and
data and
configuration data,
self-signed
certificates
11 and 26
(read/write/delete)
18, 19, 20, 21, 22, 23 and
24 (write/delete)
3, 4 (read/write)
1, 2 (read)
15 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Service Description Input Output
CSP/Algorithm Access
(see Table 9 below for details)
Configure
Controller
The Mobility Master simplifies the
management of multiple Aruba
controllers running ArubaOS 8 or
later. Key features include a
centralized dashboard to easily
see and manage controllers,
configuration hierarchy to
customize deployments for
various sites, and live firmware
and feature upgrades to improve
network reliability during active
user sessions. The addition of
licensing pools simplifies the
transfer of licenses between
different controllers to quickly
address expanded deployment
needs.
Commands and
configuration data,
SSH v2 outputs and
data, IKEv1/IKEv2
inputs and data; IPSec
inputs, commands, and
data
Status of
commands and
configuration data,
SSH v2 outputs
and data
11, 25, 26, 27, 28, 29, 30
(read/write/delete)
18, 19, 20, 21, 22, 23, 24
(write/delete)
3, 4 (read/write)
1, 2 (read)
Zeroization The cryptographic keys stored in
SDRAM memory can be zeroized
by rebooting the module. The
cryptographic keys (IKE Pre-
shared key) stored in the flash
can be zeroized by using the
command ‘wipe out flash’ or
overwriting with a new secret.
The ‘no’ command in the CLI can
be used to zeroize IKE, IPSec
and CA CSPs. Please See CLI
guide for details. The other
keys/CSPs (RSA/ECDSA public
key/private key and certificate)
stored in Flash memory can be
zeroized by using the command
"wipe out flash".
Command Progress
information
All CSPs will be destroyed.
Non-Proprietary
16 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
6.2 User Role
Table 4 below lists the services available to User role:
Table 4 User Service
Service Description Input Output CSP Access (see Table 9 below for CSP details)
IKEv1/IKEv2-
IPSec
Access the module's
IPSec services in order to
secure network traffic
IPSec inputs,
commands, and
data
IPSec
outputs,
status, and
data
5, 6, 7, 8, 9, 10 (read, write, delete)
14, 15, 16, 17, 18 (read)
19, 20, 21, 22, 23, 24, 25 (read/delete)
3, 4 (read/write)
1, 2 (read)
6.3 Unauthenticated Services
The Aruba Mobility Master can perform VLAN, bridging, firewall, routing, and forwarding functionality without authentication. These
services do not involve any cryptographic processing.
• Internet Control Message Protocol (ICMP) service
• Network Time Protocol (NTP) service
• Network Address Resolution Protocol (ARP) service
Additional unauthenticated services include performance of the power-on self-test and system status indication via LEDs.
6.4 Services Available in Non-FIPS Mode
For additional non-security-relevant services offered by the module, please refer to the ArubaOS User Guide listed in section 9.7 of the
Security Policy.
• All of the services that are available in FIPS mode are also available in non-FIPS mode.
• If not operating in the Approved mode as per the procedures in Section 9, then non-Approved algorithms and/or sizes are
available.
• Upgrading the firmware via the console port (non-approved)
• Debugging via the console port (non-approved).
• For additional non-security-relevant services offered by the module, please refer to the ArubaOS User Guide listed in section
13.5.
6.5 Non-Approved Services Non-Approved in FIPS Mode
• IPSec/IKE using Triple-DES
• SSH using HMAC-SHA-256
• Remote AP Termination
17 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
6.6 Authentication Mechanisms
The Aruba Mobility Master supports role-based authentication. Role-based authentication is performed before the Crypto Officer
enters privileged mode using admin password via Web Interface or SSHv2. Role-based authentication is also performed for User
authentication.
This includes password and RSA/ECDSA-based authentication mechanisms. The strength of each authentication mechanism is
described below.
Table 5 Estimated Strength of Authentication Mechanisms
Authentication Type Role Strength
Password-based authentication
(CLI and Web Interface)
Crypto Officer Passwords are required to be a minimum of eight ASCII characters and a
maximum of 32 with a minimum of one letter and one number. Given these
restrictions, the probability of randomly guessing the correct sequence is one (1)
in 3,608,347,333,959,680 (this calculation is based on the assumption that the
typical standard American QWERTY computer keyboard has 10 Integer digits,
52 alphabetic characters, and 32 special characters providing 94 characters to
choose from in total. The calculation should be 94^8 (Total number of 8-digit
passwords) – 84^8 (Total number of 8-digit passwords without numbers) – 42^8
(Total number of 8-digit passwords without letters) + 32^8 (Total number of 8-
digit passwords without letters or numbers, added since it is double-counted in
the previous two subtractions) = 3,608,347,333,959,680). At optimal network
conditions (assuming 1ms round-trip latency), an attacker would only get 60,000
guesses per minute. Therefore the associated probability of a successful
random attempt during a one-minute period is 60,000/3,608,347,333,959,680,
which is less than 1 in 100,000 required by FIPS 140-2.
RSA-based authentication
(IKEv1/IKEv2/TLS)
User
(Managed
Controller)
The module supports 2048-bit RSA key authentication during IKEv1, IKEv2,
TLS, and EAP-TLS. RSA 2048 bit keys correspond to 112 bits of security.
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. At optimal network conditions (assuming 1ms round-trip latency),
an attacker would only get 60,000 guesses per minute. Therefore the
associated probability of a successful random attempt during a one-minute
period is 60,000/2^112, which is less than 1 in 100,000 required by FIPS 140-2.
RSA-based authentication
(SSH/HTTP over TLS)
Crypto Officer The module supports 2048-bit RSA key authentication during IKEv1, IKEv2,
TLS, and EAP-TLS. RSA 2048 bit keys correspond to 112 bits of security.
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. At optimal network conditions (assuming 1ms round-trip latency),
an attacker would only get 60,000 guesses per minute. Therefore the
associated probability of a successful random attempt during a one-minute
period is 60,000/2^112, which is less than 1 in 100,000 required by FIPS 140-2.
Non-Proprietary
18 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
These keys can be used for admin authentication.
ECDSA-based authentication
(HTTP over TLS)
Crypto Officer ECDSA signing and verification is used to authenticate to the module during
IKEv1/IKEv2, TLS, and EAP-TLS. Both P-256 and P-384 curves are supported.
ECDSA P-256 provides 128 bits of equivalent security, and P-384 provides 192
bits of equivalent security. Assuming the low end of that range, the associated
probability of a successful random attempt is 1 in 2^128, which is less than 1 in
1,000,000 required by FIPS 140-2. At optimal network conditions (assuming
1ms round-trip latency), an attacker would only get 60,000 guesses per minute.
Therefore the associated probability of a successful random attempt during a
one-minute period is 60,000/2^128, which is less than 1 in 100,000 required by
FIPS 140-2.
ECDSA-based authentication
(IKEv1/IKEv2/TLS)
User
(Managed
Controller)
ECDSA signing and verification is used to authenticate to the module during
HTTP over TLS. Both P-256 and P-384 curves are supported. ECDSA P-256
provides 128 bits of equivalent security, and P-384 provides 192 bits of
equivalent security. Assuming the low end of that range, the associated
probability of a successful random attempt is 1 in 2^128, which is less than 1 in
1,000,000 required by FIPS 140-2. At optimal network conditions (assuming
1ms round-trip latency), an attacker would only get 60,000 guesses per minute.
Therefore the associated probability of a successful random attempt during a
one-minute period is 60,000/2^128, which is less than 1 in 100,000 required by
FIPS 140-2.
These keys can be used for admin authentication.
Pre-shared key-based
authentication (IKEv1/IKEv2)
User
(Managed
Controller)
The password requirements are the same as the CO role above, except that the
maximum ASCII characters can be 64. Additionally, exactly 64 HEX characters
can be entered. Assuming the weakest option of 8 ASCII characters, the
authentication mechanism strength is the same as the Password-based
authentication above.
SSH Master Public Certificate
(SSH)
Crypto Officer RSA-based certificates are used for authentication by the CO to connect to the
Mobility Master which provides an interface to the Controller if running as a
managed device. The authentication mechanism strength is the same as RSA-
based authentication above.
6.7 Cryptographic Key Management
6.7.1 FIPS Approved Algorithms
The firmware in each module contains the following cryptographic algorithm implementations/crypto libraries to implement the different
FIPS approved cryptographic algorithms that will be used for the corresponding security services supported by the module in FIPS
mode:
19 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
• ArubaOS OpenSSL Module algorithm implementation
• ArubaOS Crypto Module algorithm implementation
• ArubaOS Bootloader algorithm implementation
Below are the detailed lists for the FIPS approved algorithms and the associated certificate implemented by each algorithm
implementation.
Note that not all algorithm modes that appear on the module’s CAVP certificates are utilized by the module, and the tables
below list only the algorithm modes that are utilized by the module.
Non-Proprietary
20 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
The firmware supports the following cryptographic implementations.
Table 6 ArubaOS OpenSSL Module Cryptographic Algorithms
ArubaOS OpenSSL Module
CAVP
Certificate #
Algorithm Standard Mode/Method
Key Lengths,
Curves, Moduli
Use
A2690
AES
FIPS 197,
SP 800-38A
ECB, CBC, CTR (ext
only)
128, 192, 256 Data Encryption/Decryption
A2690
AES
FIPS 197,
SP 800-
38A, SP
800-38D
GCM, CCM 128, 256 Data Encryption/Decryption
Vendor Affirmed CKG SP 800-133 CTR_DRBG N/A
Cryptographic Key
Generation (using output from
DRBG1
as per IG D.12)
A2690
CVL
IKEv1, TLS,
SSH, SNMP
SP800-135
IKEv1: DSA, PSK
TLS: v1.0/1.1, v1.2
IKEv1: DH 2048-bit;
SHA-256, SHA-384
SSH: SHA-1
TLS: SHA-256, SHA-
384, SHA-512
Key Derivation
A2690 CVL
IKEv1
SP800-135 IKEv1 IKEv1: SHA-1 Key Derivation
A2690
DRBG SP 800-90A AES CTR 256
Deterministic Random
Number Generation
A2690 DSA FIPS 186-4 keyGen, pqgGen
L=2048, N=256,
SHA2-256
Key Generation, Digital Key
Generation
A2690
ECDSA 186-4
PKG, PKV, SigGen,
SigVer
P256, P384
Digital Signature
Generation, Digital
Signature Verification,
Digital Key Generation,
Digital Key Verification
A2690
HMAC FIPS 198-1
HMAC-SHA1, HMAC-
SHA2-256, HMAC-
SHA2-384, HMAC-
SHA2-512
Key Size < Block Size Message Authentication
A2690 KAS-SSC
SP 800-56A
Rev3
FFC: dhEphem,
ECC: Ephemeral Unified
FFC: FC with
SHA2-256
Key Agreement Scheme –
Shared Secret Computation
1
Resulting symmetric keys and seeds used for asymmetric key generation are unmodified output from SP 800-90A DRBG.
21 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
ECC: P-256 with
SHA2-256
KAS Roles - initiator,
responder
N/A KAS
SP 800-56A
Rev3
SP 800-135
KAS-SSC Cert A2690
CVL Cert A2690
N/A
Key Agreement Scheme –
IG D.8, scenario X1 (2)
N/A KAS
SP 800-56A
Rev3
SP 800-56C
Rev1
KAS-SSC Cert A2690
KDA Cert A2690
N/A
Key Agreement Scheme –
IG D.8, scenario X1 (2)
A2690 KDA
SP 800-56C
Rev1
Two-step key
derivation
HMAC-SHA-1,
HMAC-SHA2-256,
HMAC-SHA2-384
Key Derivation Algorithm
A2690 RSA FIPS 186-2 SHA-1 PKCS1 v1.5 2048 Digital Signature Verification
A2690
RSA FIPS 186-4
SHA-1, SHA-256, SHA-
384 PKCS1 v1.5
2048
Digital Key Generation,
Signature Generation and
Verification
A2690
SHS FIPS 180-4
SHA-1, SHA-256, SHA-
384, SHA-512 Byte Only
160, 256, 384, 512 Message Digest
A2690 Triple-DES SP 800-67 TECB, TCBC 192 Data Encryption/Decryption
AES Cert
A2690
KTS SP 800-38F AES-GCM2 128, 256
Key Wrapping/Key
Transport via IKE/IPSec
AES Cert
A2690 and
HMAC Cert
A2690
KTS SP 800-38F
AES-CBC3
HMAC-SHA-1, HMAC-
SHA-256, HMAC-SHA-
384, HMAC-SHA-512
128, 192, 256
Key Size < Block Size
Key Wrapping/Key
Transport via IKE/IPSec
Notes:
o In FIPS Mode, Triple-DES is only used in the Self-Tests and with the KEK.
o IKEv1, TLS, SSH and SNMP protocols have not been reviewed (apart from the KDF) or tested by the CAVP and CMVP.
Table 7 ArubaOS Crypto Module Cryptographic Algorithms
ArubaOS Crypto Module
CAVP Certificate # Algorithm Standard Mode/Method
Key Lengths,
Curves, Moduli
Use
A2689 AES FIPS 197, CBC, GCM 128, 192, 256 Data Encryption/Decryption
2
key establishment methodology provides 128 or 256 bits of encryption strength
3
key establishment methodology provides between 128 and 256 bits of encryption strength
Non-Proprietary
22 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
SP 800-38A
SP 800-
38D
A2689 CVL
IKEv2 (KDF)
SP800-135 IKEv2
IKEv2: DH 2048-bit;
SHA-256, SHA-384
Key Derivation
A2689 CVL
IKEv2 (KDF)
SP800-135 IKEv2 IKEv2: SHA-1 Key Derivation
A2689 DSA FIPS 186-4 keyGen, pqgGen
L=2048, N=256,
SHA2-256
Key Generation, Digital
Key Generation
A2689
ECDSA 186-4
PKG, PKV, SigGen,
SigVer
P256, P384
Digital Key Generation,
Digital Key Verification,
Signature Generation, and
Verification
A2689
HMAC FIPS 198-1
HMAC-SHA1, HMAC-
SHA-256, HMAC-
SHA-384, HMAC-
SHA-512 , HMAC-
SHA-1-96, HMAC-
SHA-256-128, HMAC-
SHA-384-192
(In FIPS Mode,
HMAC-SHA-512 is
only used in the Self-
Tests.)
Key Size < Block
Size Message Authentication
A2689
KAS-SSC
SP 800-56A
Rev3
FFC: dhEphem,
ECC: Ephemeral
Unified
FFC: FC with
SHA2-256
ECC: P-256 with
SHA2-256
KAS Roles - initiator,
responder
Key Agreement Scheme –
Shared Secret
Computation
A2689
KAS
SP 800-56A
Rev3
SP 800-135
KAS-SSC Cert
CVL Cert. A2689
N/A
Key Agreement Scheme –
IG D.8, scenario X1 (2)
A2689
RSA FIPS 186-2
SHA-1, SHA-256,
SHA-384 PKCS1 v1.5
2048
Digital Signature
Verification
A2689
RSA FIPS 186-4
SHA-1, SHA-256,
SHA-384 PKCS1 v1.5
2048
Digital Key Generation,
Signature Generation and
Verification
23 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
A2689
SHS FIPS 180-4
SHA-1, SHA-256,
SHA- 384, SHA-512
Byte Only
(In FIPS Mode, SHA-
512 is only used in the
Self-Tests)
160, 256, 384, 512 Message Digest
A2689 Triple-DES SP 800-67 TCBC 192 Data Encryption/Decryption
AES Cert A2689 KTS SP 800-38F AES-GCM4 128, 256
Key Wrapping/Key
Transport via IKE/IPSec
AES Cert A2689,
and HMAC Cert
A2689
KTS SP 800-38F
AES-CBC5
HMAC-SHA1, HMAC-
SHA-256, HMAC-
SHA-384, HMAC-
SHA-5126
128, 192, 256
Key Size < Block
Size
Key Wrapping/Key
Transport via IKE/IPSec
Notes:
o In FIPS Mode, Triple-DES is only used in the Self-Tests.
o IKEv2 protocols have not been reviewed (apart from the KDF) or tested by the CAVP and CMVP.
4
key establishment methodology provides 128 or 256 bits of encryption strength
5
key establishment methodology provides between 128 and 256 bits of encryption strength
6
In FIPS Mode, HMAC-SHA-512 is only used in the Self-Tests.
Non-Proprietary
24 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
Table 8 ArubaOS Bootloader Cryptographic Algorithms
ArubaOS Bootloader
CAVP
Certificate #
Algorithm Standard Mode/Method
Key Lengths, Curves,
Moduli
Use
A2688 RSA FIPS 186-4 SHA-1, SHA-256 2048 Digital Signature Verification
A2688 SHS FIPS 180-4
SHA-1, SHA-256 Byte
Only
160, 256 Message Digest
Note:
o Only Firmware signed with SHA-256 is permitted in the Approved mode. Digital signature verification with SHA-1, while
available within the module, shall only be used while in the non-Approved mode.
6.7.2 Non-FIPS Approved but Allowed Cryptographic Algorithms
• MD5 (used for older versions of TLS)
• NDRNG (used solely to seed the approved DRBG)
• RSA (key wrapping; key establishment methodology provides 112 bits of encryption strength)
Note: RSA key wrapping is used in TLS protocol implementation.
6.7.3 Non-FIPS Approved Cryptographic 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
• RSA (non-compliant less than 112 bits of encryption strength)
• Null Encryption
• ECDSA (non-compliant when using 186-2 signature generation)
• Triple-DES as used in IKE/IPSec
• HMAC-SHA-256 as used in SSH
• Diffie-Hellman Group14 with SHA-256
Notes:
DES, MD5, HMAC-MD5 and RC4 are used for older versions of WEP in non-FIPS mode
25 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
6.8 Critical Security Parameters
The following are the Critical Security Parameters (CSPs) used in the module.
Table 9 CSPs/Keys Used in the module
# Name Algorithm/Key Size Generation/Use Storage Zeroization
General Keys/CSPs
1 DRBG entropy input SP800-90a
CTR_DRBG
(512 bits)
Entropy inputs to the
DRBG function used to
construct the DRBG
seed. 64 bytes are gotten
from the entropy source
on each call by any
service that requires a
random number.
Stored in SDRAM
memory (plaintext)
Zeroized by rebooting
the module
2 DRBG seed SP800-90a
CTR_DRBG
(384-bits)
Input to the DRBG that
determines the internal
state of the DRBG.
Generated using DRBG
derivation function that
includes the entropy input
from the entropy source
by any service that
requires a random
number
Stored in SDRAM
memory (plaintext)
Zeroized by rebooting
the module
3 DRBG Key SP800-90a
CTR_DRBG
(256 bits)
This is the DRBG key
used for SP800-90a
CTR_DRBG.
Stored in SDRAM
memory (plaintext)
Zeroized by rebooting
the module
4 DRBG V SP800-90a
CTR_DRBG V
(128 bits)
Internal V value used as
part of SP800-90a
CTR_DRBG
Stored in SDRAM
memory (plaintext)
Zeroized by rebooting
the module
5 Diffie-Hellman private
key
Diffie-Hellman Group
14 (224 bits)
Generated internally by
calling FIPS approved
DRBG (cert # C413)
during Diffie-Hellman
Exchange. Used for
establishing DH shared
secret.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
Non-Proprietary
26 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
6 Diffie-Hellman public
key
Diffie-Hellman Group
14 (2048 bits)
Generated internally by
calling FIPS approved
DRBG (cert # C413)
during Diffie-Hellman
Exchange. Used for
establishing DH shared
secret.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
7 Diffie-Hellman shared
secret
Diffie-Hellman Group
14 (2048 bits)
Established during Diffie-
Hellman Exchange. Used
for deriving IPSec/IKE
and SSH cryptographic
keys.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
8 EC Diffie-Hellman
private key
EC Diffie-Hellman
(Curves: P-256 or P-
384).
Generated internally by
calling FIPS approved
DRBG (cert # C413)
during EC Diffie-Hellman
Exchange. Used for
establishing ECDH
shared secret.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
9 EC Diffie-Hellman
public key
EC Diffie-Hellman
(Curves: P-256 or P-
384).
Generated internally by
calling FIPS approved
DRBG (cert # C413)
during EC Diffie-Hellman
Exchange. Used for
establishing ECDH
shared secret.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
10 EC Diffie-Hellman
shared secret
EC Diffie-Hellman
(Curves: P-256 or P-
384)
Established during EC
Diffie-Hellman Exchange.
Used for deriving
IPSec/IKE and TLS
cryptographic keys.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
11 RADIUS server
shared secret
8-128 characters
shared secret
Entered by CO role. Used
for RADIUS server
authentication.
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘wipe out
flash’ or by overwriting
with a new secret
27 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
12 Crypto Officer
Password
8-32 characters
password
Entered by CO role. Used
for CO role
authentication.
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘wipe out
flash’ or by overwriting
with a new secret
13 RSA Private Key RSA 2048 bit private
key
This key is generated by
calling FIPS approved
DRBG (cert # C413) in
the module. Used for
SSH, IKEv1, IKEv2, TLS,
and OCSP (signing
OCSP messages).
This key can also be
entered by the CO
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘wipe out
flash’
14 RSA public key RSA 2048 bits public
key
This key is generated by
calling FIPS approved
DRBG (cert #C413) in the
module. This Key can be
entered by the CO.
Used for SSH, IKEv1,
IKEv2, TLS, and OCSP
(verifying OCSP
messages).
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘wipe out
flash’
15 ECDSA Private Key ECDSA suite B P-256
and P-384 curves
This key is generated by
calling FIPS approved
DRBG (cert # C413) in
the module. Used for
IKEv1, IKEv2, and TLS.
This key can also be
entered by the CO.
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘wipe out
flash’
16 ECDSA Public Key ECDSA suite B P-256
and P-384 curves
This key is generated by
calling FIPS approved
DRBG (cert # C413) in
the module. This Key can
also be entered by the
CO.
Used for IKEv1, IKEv2,
and TLS.
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘wipe out
flash’.
IPSec/IKE
Non-Proprietary
28 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
17 IKE Pre-shared secret Shared secret
(8 - 64 ASCII or 64
HEX characters)
Entered by CO role.
Used for IKEv1 and
IKEv2 peers
authentication.
Stored in Flash
memory (plaintext).
Zeroized by using
command ‘wipe out
flash’ or by overwriting
with a new secret
18 skeyid Shared Secret
(160/256/384 bits)
A shared secret known
only to IKE peers. It was
established via key
derivation function
defined in SP800-135
KDF (IKEv1). Used for
deriving other keys in
IKE protocol
implementation.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module.
19 skeyid_d Shared Secret
(160/256/384 bits)
A shared secret known
only to IKE peers. It was
derived via key
derivation function
defined in SP800-135
KDF (IKEv1). Used for
deriving IKE session
authentication key.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
20 SKEYSEED Shared Secret
(160/256/384 bits)
A shared secret known
only to IKE peers. It was
derived via key
derivation function
defined in SP800-135
KDF (IKEv2) and it will
be used for deriving IKE
session authentication
key.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
21 IKE session
authentication key
HMAC-SHA-
1/256/384
(160/256/384 bits)
The IKE session (IKE
Phase I) authentication
key. This key is derived
via key derivation
function defined in
SP800-135 KDF
(IKEv1/IKEv2). Used for
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
29 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
IKEv1/IKEv2 payload
integrity verification.
22 IKE session
encryption key
AES (128/192/256
bits, CBC)
The IKE session (IKE
Phase I) encrypt key.
This key is derived via
key derivation function
defined in SP800-135
KDF (IKEv1/IKEv2).
Used for IKE payload
protection.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
23 IPSec session
encryption key
AES (128/192/256
bits, CBC) and AES-
GCM (128/256 bits)
The IPsec (IKE phase II)
encryption key. This key
is derived via a key
derivation function
defined in SP800-135
KDF (IKEv1/IKEv2).
Used for IPSec traffics
protection.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
24 IPSec session
authentication key
HMAC-SHA-1 (160
bits)
The IPsec (IKE Phase II)
authentication key. This
key is derived via using
the KDF defined in
SP800-135 KDF
(IKEv1/IKEv2). Used for
IPSec traffics integrity
verification.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
SSHv2
25 SSHv2 session key AES (128/192/256
bits) CBC Mode, CTR
Mode
This key is derived via a
key derivation function
defined in SP800-135
KDF (SSHv2). Used for
SSHv2 traffics
protection.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
26 SSHv2 session
authentication key
HMAC-SHA-1, HMAC-
SHA1-96 (160-bit)
This key is derived via a
key derivation function
defined in SP800-135
KDF (SSHv2). Used for
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
Non-Proprietary
30 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
SSHv2 traffics integrity
verification.
TLS
27 TLS pre-master secret 48 bytes secret This key is transferred
into the module,
protected by TLS RSA
public key.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
28 TLS master secret 48 bytes secret This key is derived via
the key derivation
function defined in
SP800-135 KDF (TLS)
using the TLS Pre-
Master Secret.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
29 TLS session
encryption key
AES-CBC Mode
(128/256 bits), AES-
GCM Mode (128/256
bits)
This key is derived via a
key derivation function
defined in SP800-135
KDF (TLS). Used for
TLS traffic protection.
Uses Triple-DES when
using TLSv1.0
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
30 TLS session
authentication key
HMAC-SHA-
1/256/384
(160/256/384 bits)
This key is derived via a
key derivation function
defined in SP800-135
KDF (TLS). Used for
TLS traffic integrity
verification.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
SNMPv3
31 SNMPv3
authentication
password
8-31 characters
password
Entered by CO role.
User for SNMPv3
authentication.
Stored in Flash
memory (plaintext).
Zeroized by using
command ‘wipe out
flash’ or by overwriting
with a new secret
31 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
32 SNMPv3 engine ID 10 - 24 hex character
password
Entered by CO role. A
unique string used to
identify the SNMP
engine.
Stored in Flash
memory (plaintext).
Zeroized by using
command ‘wipe out
flash’ or by overwriting
with a new secret
33 SNMPv3 privacy key AES-CFB key (128
bits)
This key is derived via a
key derivation function
defined in SP800-135
KDF (SNMPv3). Used
for SNMPv3 traffics
protection.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
34 SNMPv3
Authentication Key
AES-CFB key (128
bits)
This key is derived via a
key derivation function
defined in SP800-135
KDF (SNMPv3). Used
for SNMPv3
authentication.
Stored in SDRAM
memory (plaintext).
Zeroized by rebooting
the module
35 SNMPv3 Privacy
Protocol Password
8 - 31 characters
password
Entered by CO role. A
unique string used to
protect SNMP privacy
protocol.
Stored in Flash
memory (plaintext).
Zeroized by using
command ‘wipe out
flash’ or by overwriting
with a new secret
Factory Key
36 Firmware Integrity
Public Key
RSA
(2048 bits)
This is an RSA public
key which is loaded into
the module during
manufacturing. Read in
by bootloader during
image verification.
Stored in firmware
image (plaintext).
The zeroization
requirements do not
apply to this key as it is
a public key
NTP
37 NTP Authentication
Key
SHA-1 (160-bit) Entered by CO role. A
unique string used for
authentication to the
NTP server.
Stored in Flash
memory (plaintext).
Zeroized by using
command ‘wipe out
flash’ or by deleting the
NTP configuration.
Mobility Master
Non-Proprietary
32 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
# Name Algorithm/Key Size Generation/Use Storage Zeroization
38 Master Public
Certificate
RSA
(2048 bits)
This key is generated by
calling FIPS approved
DRBG (cert # C413) in
the module.
Used for SSH from the
Mobility Master to
managed device when
connecting to the
controllers for
management.
Stored in Flash
memory (plaintext).
Zeroized by using
command ‘wipe out
flash’
• AES GCM IV generation is performed in compliance with the Implementation Guidance A.5 scenario 1. The AES-GCM IV is
used in the TLS and IPSec/IKEv2 protocols.
o When used with TLS, it is internally generated deterministically in compliance with TLSv1.2 GCM cipher suites as
described in SP 800-52 Rev 2, Section 3.3.1. Per RFC 5246, when the nonce explicit part of the IV exhausts the
maximum number of possible values for a given session key, the module will trigger a handshake to establish a new
encryption key.
o When used with IPSec/IKEv2, it is internally generated deterministically in compliance with RFCs 4106 and 5282.
Additionally, the module uses RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the
AES GCM encryption keys are derived. Per RFC 7296, when the IV exhausts the maximum number of possible
values for a given security association the module will trigger a rekeying with IKEv2 to establish a new encryption key
for the security association.
• CKG (vendor affirmed to SP 800-133 Rev2): For keys identified as being “Generated internally by calling FIPS approved
DRBG", the generated seed used in the asymmetric key generation is an unmodified output from the DRBG.
• The module generates a minimum of 256 bits of entropy for use in key generation.
• CSPs labeled as “Entered by CO” are entered into the module via SSH/TLS.
• CSPs generated in FIPS mode cannot be used in non-FIPS mode, and vice versa.
33 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
6.9 Self-Tests
The module performs Power On Self-Tests regardless the modes (non-FIPS mode and FIPS mode). In addition, the module also
performs Conditional tests after being configured into the FIPS mode. In the event any self-test fails, the module will enter an error
state, log the error, and reboot automatically.
The module performs the following POSTs (Power On Self-Tests):
• ArubaOS OpenSSL Module (Firmware)
o AES (Encrypt/Decrypt) KATs
o DRBG KATs
o ECDSA (P-256, P-384) (Sign/Verify) KATs
o HMAC (HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 and HMAC-SHA2-512) KATs
o KAS-SSC (SP 800-56A Rev3) KATs (FFC and ECC)
o KDA (SP 800-56C Rev1) KAT (two-step KDF with HMAC)
o KBKDF KAT
o KDF135 KATs (IKEv1 KDF, TLS KDF, SSH KDF, SNMP KDF)
o RSA (2048) (Sign/Verify) KATs
o SHS (SHA-1, SHA2-256, SHA2-384 and SHA2-512) KATs
o Triple-DES (Encrypt/Decrypt) KATs
• ArubaOS Crypto Module (Firmware)
o AES (Encrypt/Decrypt) KATs
o AES-GCM (Encrypt/Decrypt) KATs
o KAS-SSC (SP 800-56A Rev3) KATs (FFC and ECC)
o ECDSA (Sign/Verify) KATs
o HMAC (HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512) KATs
o RSA (Sign/Verify) KATs
o SHS (SHA-1, SHA-256, SHA-384 and SHA-512) KATs
o Triple-DES (Encrypt/Decrypt) KATs
• ArubaOS Bootloader (Firmware)
o Firmware Integrity Test: RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA-256 (the integrity test is the
KAT)
The module performs the following Conditional Tests:
• ArubaOS OpenSSL Module (Firmware)
o Bypass Tests (Wired Bypass Test and Wireless Bypass Test)
o CRNG Test on Approved DRBG
Non-Proprietary
34 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
o CRNG Test for NDRNG
o ECDSA Pairwise Consistency Test
o Firmware Load Test - RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA-256
o RSA Pairwise Consistency Test
o SP800-90A Section 11.3 Health Tests for CTR_DRBG (Instantiate, Generate and Reseed)
o DSA Pairwise Consistency Test
o SP800-56A Rev3 assurances as per SP 800-56A Rev3 Sections 5.5.2, 5.6.2 and 5.6.3.
• ArubaOS Crypto Module (Firmware)
o ECDSA Pairwise Consistency Test
o RSA Pairwise Consistency Test
o Diffie-Hellman Pairwise Consistency Test
o DSA Pairwise Consistency Test
o SP800-56A Rev3 assurances as per SP 800-56A Rev3 Sections 5.5.2, 5.6.2 and 5.6.3.
Upon successful completion of the power-up self tests, the module logs a KATS: passed message to the console
35 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
7 Installing the Mobility Master Hardware Appliance
This chapter covers the physical installation of the Mobility Master with FIPS 140-2 Level 1 validation. The Crypto Officer is responsible
for ensuring that the following procedures are used to place the Mobility Master in a FIPS-approved mode of operation.
This chapter covers the following installation topics:
• Precautions to be observed during installation
• Requirements for the Mobility Master components and rack mounting gear
• Selecting a proper environment for the Mobility Master
• Mounting the Mobility Master in a rack
• Connecting power to the Mobility Master
7.1 Pre-Installation Checklist
You will need the following during installation:
• Aruba Mobility Master components.
• Phillips or cross-head screwdriver.
• Equipment rack.
• 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 SSHv2 software.
• A 4- or 8-conductor Category 5 UTP Ethernet cable.
7.2 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 Mobility Master 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
Mobility Master 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 components must be performed in a static-free environment. The proper use of
anti-static body straps and mats is strongly recommended.
• Keep components in anti-static packaging when not installed in the chassis.
• Do not ship or store this product near strong electromagnetic, electrostatic, magnetic or radioactive fields.
• Do not disassemble chassis or components. They have no internal user-serviceable parts. When service or repair is needed,
contact Aruba Networks.
Non-Proprietary
36 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
7.3 Product Examination
The units are shipped to the Crypto Officer in factory-sealed boxes using trusted commercial carrier shipping companies. The Crypto
Officer should examine the carton for evidence of tampering. Tamper-evidence includes tears, scratches, and other irregularities in the
packaging.
7.4 Package Contents
The product carton should include the following:
• Mobility Master Appliance
• Rack mounting kit (optional)
• Aruba User Documentation
8 Installing the Mobility Master Virtual Appliance
This chapter covers the installation of the MM-VA with FIPS 140-2 Level 1 validation. The Crypto Officer is responsible for ensuring that
the following procedures are used to install the module properly.
This chapter covers the following installation topics:
• Requirements for the module components
• Selecting a proper environment for the module
• Install the module on the hypervisor server
• Power on the module using virtual machine management client
8.1 Pre-Installation Checklist
You will need the following during installation:
• Aruba MM-VA components (host server, MM-VA installation disk).
• 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 virtual machine management client software.
8.1.1 Product Examination
The units are shipped to the Crypto Officer in factory-sealed boxes using trusted commercial carrier shipping companies. The Crypto
Officer should examine the carton for evidence of tampering. Tamper-evidence includes tears, scratches, and other irregularities in the
packaging.
8.1.2 Package Contents
The product carton should include the following:
• Aruba MM-VA Installation CD
• Aruba User Documentation CD
37 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
9 Ongoing Management
The Aruba Mobility Master meets FIPS 140-2 Level 1 requirements. The information below describes how to keep the Mobility Master
in FIPS-approved mode of operation. The Crypto Officer must ensure that the Mobility Master is kept in a FIPS-approved mode of
operation.
9.1 Crypto Officer Management
The Crypto Officer must ensure that the Mobility Master 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 Mobility Master before Users are permitted to use the Mobility Master (see “Enabling FIPS
Mode”)
• The admin role must be root.
• Passwords must be at least eight characters long.
• VPN services can only be provided by IPsec or L2TP over IPsec.
• Access to the Mobility Master 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 Mobility Master logs must be monitored. If a strange activity is found, the Crypto Officer should take the Mobility Master
off line and investigate.
• All configuration performed through the Mobility Master when configured as a managed device must ensure that only the
approved algorithms and services are enabled on the FIPS-enabled Mobility Master.
• The guidelines in Sections 6.6.3 and 9 of this SP must be adhered to.
9.2 User Guidance
The User accesses the Mobility Master VPN functionality as an IPsec client. Although outside the boundary of the Mobility Master, the
User should be directed to be careful not to provide authentication information and session keys to others parties. The Mobility Master
communicates with the Mobility Controller through VPN functionality as an IPsec client.
9.3 Setup and Configuration
The Aruba Master meets FIPS 140-2 Level 1 requirements. The sections below describe how to place and keep the Mobility Master in
FIPS-approved mode of operation. The Crypto Officer (CO) must ensure that the Mobility Master is kept in a FIPS-approved mode of
operation.
The Mobility Master can operate in two modes: the FIPS-approved mode, and the standard non-FIPS mode. By default, the Mobility
Master operates in non-FIPS mode.
9.4 Setting Up Your Mobility Master
To set up your Mobility Master:
1. Make sure that the Mobility Master is not connected to any device on your network.
2. Boot up the Mobility Master.
3. Connect your PC or workstation to a line port (or virtual port) on the Mobility Master.
Non-Proprietary
38 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
For further details, see the Aruba Mobility Master Hardware Appliance Installation Guide listed under Section 9.7.
9.5 Enabling FIPS Mode
For FIPS compliance, users cannot be allowed to access the Mobility Master until the CO changes the mode of operation to FIPS
mode. The CO can enable FIPS mode through the CLI as identified under Section 9.5.6 below.
Once FIPS mode is enabled, the CO should also ensure that the serial port has been disabled through the following command (the
serial port must be disabled while operating under the FIPS approved mode of operation):
(config) #mgmt-user console-block
9.5.1 Enabling FIPS Mode with the CLI
Login to the Mobility Master using an SSHv2 client. Enable FIPS mode using the following commands:
#configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(config) #fips enable
(config) #exit
#write memory
Saving Configuration...
Configuration Saved.
To verify that FIPS mode has been enabled, issue the command “show fips”.
9.6 Disallowed FIPS Mode Configurations
When you enable FIPS mode, the following configuration options are disallowed:
• All WEP features
• TKIP mixed mode
• Any combination of DES, MD5, and PPTP
• Firmware images signed with SHA- 1
• Enhanced PAPI Security
• Null Encryption
• TLS with Diffie-Hellman Group 2
• Certificates with less than 112 bits security strength as used with IKEv1, IKEv2, IPSec, TLS, SSH, and/or user authentication.
• Telnet
• Diffie-Hellman Group14 with SHA-256.
• IPSec/IKE using Triple-DES
• SSH using HMAC-SHA-256
• Remote AP Termination
In addition to the above options, use of backups (via the backup command) are only permitted under FIPS mode if the backup is
immediately transferred out of the module via SCP and then deleted from flash.
39 | Aruba Virtual and Hardware Mobility Master Appliances - FIPS 140-2 Level 1 Security Policy
9.7 Full Documentation
Full documentation can be found at the links provided below.
https://asp.arubanetworks.com/downloads;fileTypes=DOCUMENT;products=Aruba%20Mobility%20Controllers%20%28A
OS%29