Ruckus FastIron ICX ™ 7450 Series Switch/Router

Certificate

Approved Algorithms (33)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Ruckus FastIron ICX ™ 7450 Series Switch/Router
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>IronWare OS 09.0.10</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Update Firmware</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Perform Self-test<br/>Show Status<br/>Perform Self- test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>bootloader<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C1,C2,C3,C5,C6 clue;
  class I1,I2,I3,I5,I6 infer;
  class R1,R2,R3,R5,R6 risk;
  class E1,E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Ruckus FastIron ICX ™ 7450 Series Switch/Router
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>IronWare OS 09.0.10</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Update Firmware</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Perform Self-test<br/>Show Status<br/>Perform Self- test</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>bootloader<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C1,C2,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Ruckus FastIron ICX™ 7450 Series Switch/Router Firmware Version: IronWare OS 09.0.10 Document Version: 1.5 Last Update Date: 10-04-2024 Prepared by: Ruckus Wireless LLC Salarpuria Supreme, #137, Marathahalli Bangalore, Karnataka 560037 India www.commscope.com

This is a non-proprietary cryptographic module security policy for Ruckus FastIron ICX™ 7450 Series Switch/Router (hereinafter referred to as the module). The firmware version running on each module is IronWare OS 09.0.10. This security policy describes how the module meets the FIPS 140-3 Level 1 security requirements, and how to operate the module in an approved mode. This security policy may be freely distributed. FIPS 140-3 (Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the NIST website at https://csrc.nist.gov/projects/cryptographic-module-validation-program. The table below indicates the actual security levels for each area of the module. Table 1 - Security Levels The module is designed to meet an overall security level 1. N/A N/A

2. Cryptographic Module Specification Cryptographic Boundary The module is a hardware, multi-chip standalone cryptographic module. The cryptographic boundary is defined as the module’s chassis unit encompassing the "top," "front," "left," "right," “rear” and "bottom" surfaces of the case representing the module’s physical perimeter. This section illustrates the module hardware with the help of photographs. Figure 1 - Front/top side of ICX7450-48P with IPSec module inserted Figure 2 - Back side of ICX7450-48P with IPSec module inserted Figure 3 - Front/top side of ICX7450-24P with ICX7400-4X10GF, ICX7400-4X1GF, ICX7400-4X10GC and ICX7400-1X40GQ and ICX7400-SERVICE MOD

Figure 4- Back side of ICX7450-24P with ICX7400-4X10GC, ICX7400-1X40GQ and ICX7400-4X10GF Figure 5 - Front/top side of ICX7450-48P with ICX74004X1GF, ICX7400-4X10GC and ICX7400-4X10GF

Figure 6 - ICX7450-48P with ICX7400-4X1GF, ICX7400-4X10GF, ICX7400-4X10GC, ICX74001X40GQ, ICX7400-SERVICE-MOD Figure 7 - Front/top side of ICX7450-48F with ICX7400-4X1GF, ICX7400-4X10GC and ICX7400-4X10GF

The module delivers the performance, flexibility, and scalability required for enterprise access deployment. Table 2 below lists the model and firmware version included in this validation.

Table 2

• Tested Operational Environments

Modes of Operation By default, the module is delivered with a non-approved mode of operation but supports an approved mode of operation. Once the module is configured to operate in the approved mode of operation by following the steps in section "Secure Operation" of this document by the Crypto Officer, the module can only operate in the approved mode. The module does not claim implementation of a degraded mode of operation. The tables below list all approved or vendor-affirmed security functions of the module, including specific key size(s) (in bits unless noted otherwise) employed for Approved services, and implemented modes of operation. There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in these tables. Approved Security Functions The module implements the following approved cryptographic algorithms that have been ACVP certified. N/A

N/A N/A N/A

• HMAC-SHA2256 HMAC-SHA2384

N/A N/A N/A Table 3 - Approved Algorithms (Crypto Library I) Table 4 - Approved Algorithms (Crypto Library II) Table 5 - Approved Algorithms (Crypto Library III)

• There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in Tables 3-5.

• The module’s AES-GCM implementation conforms to IG C.H scenario #1 following RFC

5288 for TLS. The module is compatible with TLSv1.2 and provides support for the acceptable

GCM cipher suites from SP 800-52 Rev1, Section 3.3.1. The operations of one of the two parties involved in the TLS key establishment scheme were performed entirely within the cryptographic boundary of the module being validated. The counter portion of the IV is set by the module within its cryptographic boundary. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established.

• The module’s AES-GCM implementation conforms to IG C.H scenario #1 following RFC

7296 for IPSec/IKE. The module uses RFC 7296 compliant IPSec/IKE to establish the shared

secret SKEYSEED from which the AES GCM encryption keys are derived. The operations of one of the two parties involved in the IKE key establishment scheme shall be performed entirely within the cryptographic boundary of the module being validated. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established.

• The AES GCM IV is generated internally in the cryptographic module in accordance with IEEE 802.1AE and its amendments. The IV length used is 96 bits (per SP800-38D and FIPS 140-3 IG C.H). The AES GCM IV construction is performed in compliance with IEEE 802.1AE and its amendments. If the module loses power, then new AES GCM keys should be established. The module should only be used with FIPS 140-3 validated modules when supporting the MACsec protocol for providing Peer, Authenticator functionality. The Peer and the Authenticator Modules Security Policies shall state that the link between the Peer and the Authenticator should be secured to prevent the possibility for an attacker to introduce foreign equipment into the local area network.
• No parts of the SSH, TLS, SNMP and IKEv2 protocols, other than the KDFs, have been tested by the CAVP and CMVP. As the module can only be operated in the Approved mode of operation, and any algorithms not listed in the tables 3-5 above will be rejected by the module while in the approved mode, the tables defined in SP800-140B for the following categories are missing from this document.
• Non-Approved Algorithms Allowed in Approved Mode of Operation
• Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed
• Non-Approved Algorithms Not Allowed in Approved Mode of Operation

3. Cryptographic Module Interfaces interfaces provided by the module are mapped to the following FIPS 140-3 defined logical logical interfaces and their mapping are described in the following table. Please note that the N/A N/A Table 6 – Ports and Interfaces
4. Roles, Services, and Authentication The module supports role-based authentication. In approved mode, the cryptographic module supports the following roles:
5. Crypto Officer Role: The Crypto Officer role has complete access to the system. The Crypto Officer is the only role that can perform firmware loading, security functions configuration (SSHv2, TLSv1.1/v1.2, SNMPv3, IPSec/IKEv2 and MACSec) and account management. A crypto officer can create additional accounts thereby creating additional crypto officers.
6. Port Config Admin Role: The Port Config Admin role has read and write access for configuring specific ports but not for global (system‐wide) parameters.
7. User Role: The User role on the device has read-only privileges and no configuration mode access. The module does not support the maintenance role. For all other services, an operator must authenticate to the module as described in Table below. The module provides services for remote communication (SSHv2 and SNMPv3) for management and configuration of cryptographic functions. The following subsections describe services available to operators based on role.

N/A N/A n n n N/A N/A R G, R, W, E N/A G, R, W, E N/A N/A N/A HMAC-SHA1, HMAC-SHA2256, KAS-ECCSSC, KAS-FFCSSC, HMAC-SHA1, HMAC-SHA2256, HMAC-SHA2384, KAS-ECCSSC, R, W, G R, W, G N/A

KAS-FFCSSC, HMAC-SHA1, HMAC-SHA2256, HMAC-SHA2384 HMAC-SHA2256, HMAC-SHA2384, KAS-ECCSSC, KAS-FFCSSC, R, W, G G, R, W G, R, W

N/A HMAC-SHA1, HMAC-SHA2256, KAS-ECCSSC, KAS-FFCSSC, HMAC-SHA1, HMAC-SHA2256, HMAC-SHA2384, KAS-ECCSSC, KAS-FFCSSC, N/A R, E W R, W, G N/A R, W, G N/A

HMAC-SHA1, HMAC-SHA2256, HMAC-SHA2384 HMAC-SHA2256, HMAC-SHA2384, KAS-ECCSSC, KAS-FFCSSC, R, W, G R, E R, E Table 11 - Approved Services G = Generate: The module generates or derives the SSP R = Read: The SSP is read from the module (e.g. the SSP is output)

W = Write: The SSP is updated, imported, or written to the module E = Execute: The module uses the SSP in performing a cryptographic operation Z = Zeroise: The module zeroises the SSP Unauthenticated Services The services for someone without an authorized role are to view the status output from the module’s LEDs and to cycle power the module.

5. Software/Firmware Security Integrity Techniques The module performs the Firmware Integrity tests by using CRC-32 during the Pre-Operational Self-Test. At Module’s initialization, the integrity of the runtime executable binary file is verified using the following two integrity check mechanisms to ensure that the module has not been tampered: • • Bootloader Integrity Test (CRC-32) Firmware Integrity Test (CRC-32) If at the load time the CRC-32 value does not match the stored, known CRC-32 value, the module would enter to an Error state with all crypto functionality inhibited. In addition, the module also supports the firmware load test by using RSA 2048 bits with SHA2256 (RSA Cert. #A2345) for the new validated firmware to be uploaded into the module. A Firmware Load Test Key was preloaded to the module’s binary at the binary the factory and used for firmware load test. In order to load new firmware, the Crypto Officer must authenticate into the module before loading any firmware. This ensures that unauthorized access and use of the module is not performed. The module will load the new update upon reboot. The update attempt will be rejected if the verification fails. Integrity Test On-Demand Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power-cycle or reboot the module to initiate the firmware integrity test on-demand. This automatically performs the integrity test of all firmware components included within the boundary of the module.
6. Operational Environment The module is a hardware module. The module’s operational environment is non-modifiable. The module’s firmware version running on each model is IronWare OS 09.0.10. Any other firmware loaded into these modules is out of the scope of this validation and requires a separate FIPS 140-3 validation.
7. Physical Security The module is a multi-chip standalone hardware cryptographic module. The module meets the FIPS 140-3 Level 1 security requirements as production grade equipment.

8. Non-Invasive Security No approved non-invasive attack mitigation test metrics are defined at this time.
9. Sensitive Security Parameter Management N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A P-256, P384

HMAC-SHA2256, HMAC-SHA2384 N/A N/A N/A N/A N/A

P-256, P384 P-256, P384 P-256, P384 TLS PreMaster N/A N/A HMAC-SHA2256, HMAC-SHA2384 N/A N/A N/A N/A N/A N/A N/A N/A N/A

N/A N/A N/A N/A N/A N/A Table 12 - SSPs Notes:

1. The module uses procedural zeroization to explicitly zeroize all SSPs listed in Table 12.
2. The zeroization operations shall be performed under the control of the CO role by using the CLI command “fips zeroize all”
3. To initiate zeroization, see Section End of Life / Sanitization in this document for more
4. The zeroized SSPs cannot be retrieved or reused. Once the command is initiated, the SSPs are overwritten with 0s. Table 13 – Non-Deterministic Random Number Generation Specification
5. Self-Test The modules perform the following self-tests, including the pre-operational self-tests and conditional self-tests. The module runs all self-tests without operator intervention. In the event that a self-test fails, the module will enter an error state, output an error message and follow up with a

module reboot. The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling). Pre-Operational Self-Tests:

• Pre-Operational Firmware Integrity Test
• BootLoader Integrity Test (CRC-32)
• Firmware Integrity Test (CRC-32)
• No Pre-Operational Bypass Test
• No Pre-Operational Critical Functions Test Conditional Self-Tests
• Conditional Cryptographic Algorithm Tests:
• AES-CBC 128 bits encryption KAT
• AES-CBC 128 bits decryption KAT
• AES-CMAC 128 bits encryption KAT
• AES-CMAC 128 bits decryption KAT
• AES-GCM 128 bits authenticated encryption KAT
• AES-GCM 128 bits authenticated decryption KAT
• CTR_DRBG Instantiate KAT
• CTR_DRBG Generate KAT
• CTR_DRBG Reseed KAT Note: DRBG Health Tests as specified in SP800-90Arev1 Section 11.3 are performed
• ECDSA P-256 with SHA2-256 SigGen KAT
• ECDSA P-256 with SHA2-256 SigVer KAT
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-384 KAT
• KAS-FFC-SSC Primitive KAT
• KAS-ECC-SSC Primitive KAT
• RSA 2048 bits modulus with SHA2-256 SigGen KAT
• RSA 2048 bits modulus with SHA2-256 SigVer KAT
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-384 KAT
• KBKDF KAT
• KDF SSH KAT
• KDF SNMP KAT
• KDF IKEv2 KAT
• KDF TLS KAT
• SP800-90B Entropy Source start-up health tests:
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT)
• SP800-90B Entropy Source Continuous Health Tests:
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT)

In addition, the module also performs the Conditional Cryptographic Algorithm Self-tests to the following two AES-GCM algorithms: o o o

• AES-GCM 128 bits authenticated encryption KAT for AES Cert. #4550 AES-GCM 128 bits authenticated decryption KAT for AES Cert. #4550 AES-GCM 128 bits authenticated encryption KAT for AES Cert. #5074 AES-GCM 128 bits authenticated decryption KAT for AES Cert. #5074
• Conditional Pair-Wise Consistency Tests:
• RSA PCT
• ECDSA PCT
• KAS-ECC PCT
• KAS-FFC PCT
• o Firmware Load Test (RSA 2048 bits modulus with SHA2-256)
• No Conditional Manual Entry Test No Conditional Bypass Test No Conditional Critical Function Test Error Handling If any of the above-mentioned self-tests fail, the module reports the cause of the error and enters an error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to reboot the module and reperforming the selftests, including the pre-operational software integrity test and the conditional CASTs. The module will only enter into the operational state after successfully passing the pre-operational firmware integrity test and the conditional CASTs. The table below shows the different causes that lead to the Error State and the status indicators reported. Table 14
• Error State Indicators Periodic/On-Demand Self-Test The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling). The full suite of selftests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.

In addition, the Crypto Officer shall perform the periodic test on demand no more than 10 days to ensure all components are functioning correctly.

11. Life-cycle Assurance The module is designed to handle the various stages of a module’s life-cycle. The sections below highlight the details for each stage. Secure Operation The module meets all the Level 1 requirements for FIPS 140-3. Follow the secure operations provided below to place the module in approved mode. Operating this module without maintaining the following settings will remove the module from the approved mode of operation. The module runs firmware version IronWare OS 09.0.10. This is the only allowable firmware image for this current approved mode of operation. The Crypto Officer shall load the FIPS 140-3 validated firmware only to maintain validation. The module is initiated into the approved mode of operation via the following procedures through the Command Line interface (CLI):
12. The Crypto Officer must login by using the default login password.
13. The Crypto Officer shall replace the default login password with a new one upon the firsttime authentication.
14. The Crypto Officer shall create the account for Port Config Admin role and User role respectively.
15. Enter into the configuration mode by using ‘conf t’ command.
16. Enable approved mode by using ‘fips enable’ command.
17. Configure SSH, TLS, SNMPv3, MACSec, IPSec/IKE and Radius services by using only approved algorithms listed in Tables 3, 4 and 5 above.
18. Configure the module as the MACSec Peer Authenticator in the MACSec service.
19. If using RADIUS server for roles authentication, please configure a secure TLS tunnel to secure traffic between the module and the RADIUS server. The RADIUS shared secret must be at least 8 characters long.
20. Disable the TFTP server.
21. Ensure that installed digital certificates are signed using approved algorithms.
22. Save the configuration.
23. Reload the module.
24. Verify the approved mode by using command ‘fips show’ (This command outputs the module’s status. After the approved mode was enabled, the output would be “approved mode: Administrative status ON”). Once the module has completed initialization into the approved mode of operation, the module automatically enforces a password change for the Crypto Officer. The default login password won’t be accepted by the module. Any non-approved algorithms or security functions are rejected automatically by the module and an error message is output.

End of Life / Sanitization Crypto Officers should follow the procedure below for the secure destruction of their module: Note: This process will cause the module to no longer function after it has wiped all 1. 2. 3. a.

4. Access the module via SSH with Crypto Officer. Authenticate using proper credentials. Execute command: “fips zeroize all”. Confirm command. Module will begin zeroization process and wipe all security parameters and configurations.
5. Mitigation of Other Attacks This module is not designed to mitigate against any other attacks outside of the FIPS 140-3 scope. I. Terms and Definitions

Referenced URLs

• www.commscope.com
• https://csrc.nist.gov/projects/cryptographic-module-validation-program