Aruba Mobility Controller and Access Point Series Security Target Version 1.0 09/29/2014 Prepared for: Aruba Networks, Inc.
Security Target Version 1.0 9/29/2014 1. SECURITY TARGET INTRODUCTION ...........................................................................................................4 1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION ........................................................................................4 1.2 CONFORMANCE CLAIMS .................................................................................................................................7 1.3 CONVENTIONS ........................
Security Target Version 1.0 9/29/2014 8.1.1 Security Objectives Rationale for the TOE and Environment.............................................................. 80 8.2 SECURITY REQUIREMENTS RATIONALE ........................................................................................................ 84 8.2.1 Security Functional Requirements Rationale....................................................................................... 84 8.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE...............
Security Target Version 1.0 9/29/2014 1. Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is a Wireless Local Area Network (WLAN) access system comprising Aruba Mobility Controllers and Access Points (both with an embedded ArubaOS).
Security Target Product Aruba 7210 Mobility Controller (FIPS) Aruba 7220 Mobility Controller (FIPS) Aruba 7240 Mobility Controller (FIPS) Aruba 6000 Mobility Controller (FIPS) Aruba 3200 Mobility Controller (FIPS) Aruba 3400 Mobility Controller (FIPS) Aruba 3600 Mobility Controller (FIPS) Aruba 650 Branch Office Controller (FIPS) Version 1.
Security Target Aruba 620 Branch Office Controller (FIPS) Version 1.0 9/29/2014 • 620-F1 • 620-USF1 • Policy Enforcement Firewall • RFprotect • Advanced Cryptography 6.3.1.5-FIPS AP-92 Access Point • AP-92-F1 N/A 6.3.1.5-FIPS AP-93 Access Point • AP-93-F1 N/A 6.3.1.5-FIPS AP-104 Access Point • AP-104-F1 N/A 6.3.1.5-FIPS AP-105 Access Point • AP-105-F1 N/A 6.3.1.5-FIPS AP-114 Access Point • AP-114-F1 N/A 6.3.1.5-FIPS AP-115 Access Point • AP-115-F1 N/A 6.3.1.
Security Target Version 1.0 9/29/2014 1.2 Conformance Claims This TOE is conformant to the following CC specifications: • Protection Profile for Wireless Local Area Network (WLAN) Access Systems, version 1.0, 01 December 2011 (WLASPP) • Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 3, July 2009.
Security Target Version 1.
Security Target Version 1.0 9/29/2014 2. TOE Description The Target of Evaluation (TOE) consists of Aruba Mobility Controller appliances and access points, running ArubaOS v6.3.1.5-FIPS. The TOE is a Wireless Local Area Network (WLAN) access system comprising Aruba Mobility Controllers, Access Points, and the ArubaOS. The WLAN PP defines this technology type as “one or more components that provide secure wireless access to a wired or wireless network”.
Security Target Version 1.0 9/29/2014 traffic (data from wireless clients) over the IP wired network. As a result, APs can be distributed as necessary and need not be kept in close proximity with a physically secure connection to the associated Controller. In an encrypted WLAN, a wireless client first associates with an AP and then authenticates (IEEE 802.11i 4) using credentials to obtain access to the network (an IP address) and establish a session with the TOE.
Security Target Version 1.
Security Target Version 1.0 9/29/2014 Product Aruba 7200 Series Aruba 6000/M3 Aruba 3000 Series Aruba 620/650 Max. # of Max. # of Typical Deployment APs Users 2,048 32,768 Headquarters/ Large Campus 512 8,192 Headquarters/ Large Campus 128 2,048 Medium/Large Enterprise/Campus 16 256 Branch Office The Aruba AP is a hardware device that is enclosed in a plastic or metal casing. All APs contain chips to provide IEEE 802.11 wireless LAN functionality.
Security Target • Version 1.0 9/29/2014 ArubaOS version 6.3.1.5-FIPS The differences in the models include the number of ports, interfaces, throughput and processing speed, memory and storage. Although these models have different specifications (in terms of performance and capabilities), they all provide the same security functions described in the ST; therefore, they have been considered to be the same for the purposes of the ST description. There is no difference between the products and the TOE.
Security Target • Security audit • Cryptographic support • User data protection • Identification and authentication • Security management • Protection of the TSF • Resource utilisation • TOE access • Trusted path/channels Version 1.0 9/29/2014 The TOE protects itself from tampering and bypass through several mechanisms implemented by the TOE and the operating environment.
Security Target Version 1.0 9/29/2014 internal database or authentication server). The TOE requires identification and authentication (either locally or remotely through external authentication server, internally, or both) of administrators managing the TOE. Wireless clients are identified and authenticated by different authentication mechanisms such as 802.1X, etc. More detailed information is provided in section 6.1.4.
Security Target Version 1.
Security Target Version 1.0 9/29/2014 3. Security Problem Definition The Security Problem Definition (composed of organizational policies, threat statements, and assumption) has been drawn from the Protection Profile for Wireless Local Area Network (WLAN) Access Systems, version 1.0, 01 December 2011 (WLASPP). The WLASPP offers additional information about the identified threats, but that has not been reproduced here and the WLASPP should be consulted if there is interest in that material.
Security Target Version 1.0 9/29/2014 T.UNDETECTED_ACTIONS Malicious remote users or external IT entities may take actions that adversely affect the security of the TOE. These actions may remain undetected and thus their effects cannot be effectively mitigated. T.USER_DATA_REUSE User data may be inadvertently sent to a destination not intended by the original sender. 3.3 Assumptions A.NO_GENERAL_PURPOSE It is assumed that there are no general-purpose computing capabilities (e.g.
Security Target Version 1.0 9/29/2014 4. Security Objectives Like the Security Problem Definition, the Security Objectives have been drawn from the Protection Profile for Wireless Local Area Network (WLAN) Access Systems, version 1.0, 01 December 2011 (WLASPP). The WLASPP offers additional information about the identified security objectives, but that has not been reproduced here and the WLASPP should be consulted if there is interest in that material.
Security Target Version 1.0 9/29/2014 O.SESSION_LOCK The TOE shall provide mechanisms that mitigate the risk of unattended sessions being hijacked. O.SYSTEM_MONITORING The TOE will provide the capability to generate audit data and send those data to an external IT entity. O.TIME_STAMPS The TOE shall provide reliable time stamps and the capability for the administrator to set the time used for these timestamps. O.
Security Target Version 1.0 9/29/2014 5. IT Security Requirements This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort. The SFRs have all been drawn from the Protection Profile (PP): Protection Profile for Wireless Local Area Network (WLAN) Access Systems, version 1.0, 01 December 2011 (WLASPP).
Security Target Requirement Class FAU: Security audit FCS: Cryptographic support FDP: User data protection FIA: Identification and authentication FMT: Security management FPT: Protection of the TSF Version 1.0 9/29/2014 Requirement Component FAU_GEN.1: Audit Data Generation FAU_GEN.2: User Audit Association FAU_SAR.1: Audit Review FAU_SAR.2: Restricted Audit Review FAU_SEL.1: Selective Audit FAU_STG.1: Protected Audit Trail Storage (Local Storage) FAU_STG_EXT.
Security Target Version 1.0 9/29/2014 Requirement Class FRU: Resource utilisation FTA: TOE access FTP: Trusted path/channels Requirement Component FPT_RPL.1: Replay Detection FPT_STM.1: Reliable Time Stamp FPT_TST_EXT.1: Extended: TSF Testing FPT_TUD_EXT.1: Extended: Trusted Update Resource Utilization (FRU) FRU_RSA.1: Maximum Quotas TOE Access (FTA) FTA_SSL.3: TSF-initiated termination FTA_SSL.4: User-initiated termination FTA_SSL_EXT.1: TSF-initiated session locking FTA_TAB.
Security Target Version 1.0 9/29/2014 Requirement Auditable Events FCS_CKM.1(2) Failure of the key generation activity. Failure of the key generation activity. Failure of the key distribution activity, including failures related to wrapping the GTK. Failure of the key zeroization process. FCS_CKM.2(1) FCS_CKM.2(2) FCS_CKM_EXT.4 FCS_COP.1(1) Failure of encryption or decryption. FCS_COP.1(2) Failure of cryptographic signature. FCS_COP.1(3) Failure of hashing function. FCS_COP.
Security Target Version 1.0 9/29/2014 Requirement Auditable Events FCS_SSH_EXT.1 Protocol failures. Establishment/Termination of an SSH session. FCS_TLS_EXT.1 Protocol failures. Establishment/Termination of a TLS session. FDP_RIP.2 FIA_8021X_EXT.1 None Attempts to access to the 802.1X controlled port. FIA_AFL.1 FIA_PMG_EXT.1 FIA_PSK_EXT.1 FIA_UAU.6 The reaching of the threshold for the unsuccessful authentication attempts and the actions taken (e.g.
Security Target Requirement Version 1.0 9/29/2014 Auditable Events Additional Audit Record Content Guidance Notes was loaded or removed. FMT_MOF.1 FMT_MTD.1(1) FMT_MTD.1(2) FMT_MTD.1(3) FMT_SMF.1 FMT_SMR.1 FPT_FLS.1 None None None None None None Failure of the TSF. FPT_ITT.1 FPT_RPL.1 None Detected replay attacks. FPT_STM.1 FPT_TST_EXT.1 None Execution of this set of TSF self-tests. Detected integrity violations. Initiation of the update. Any failure to verify the integrity of the update.
Security Target Requirement FTP_ITC.1 FTP_TRP.1 Version 1.0 9/29/2014 Auditable Events Additional Audit Record Content mechanism. All attempts to establish a trusted channel. Detection of modification of channel data. Identification of the initiator and target of channel. All attempts to establish a remote administrative session. Detection of modification of session data. Identification of the initiating IT entity (e.g., IP address). Guidance Notes The Inter-TSF trusted channel is IPsec.
Security Target Version 1.0 9/29/2014 mechanisms directly. For example, testing to ensure the TOE can detect replay attempts will more than likely be done to demonstrate that requirement FPT_RPL.1 is satisfied. Another example is that testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as expected. FAU_GEN.1.
Security Target Version 1.0 9/29/2014 Test 2 [conditional]: If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability is correctly implemented. The evaluator shall also, in the test plan, provide a short narrative justifying the set of tests as representative and sufficient to exercise the capability. 5.2.1.
Security Target Version 1.0 9/29/2014 The evaluator shall examine the administrative guidance to ensure it instructs the administrator how to establish communication with the audit server. The guidance must instruct how this channel is established in a secure manner (e.g., IPsec, TLS). The evaluator checks the administrative guidance to determine what action(s) is taken if the link between the TOE and audit server is broken.
Security Target Version 1.0 9/29/2014 Component Assurance Activity: The evaluator shall use the key pair generation portions of 'The FIPS 186-3 Digital Signature Algorithm Validation System (DSA2VS)', 'The FIPS 186-3 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)', and 'The RSA Validation System (RSA2VS)' as a guide in testing the requirement above, depending on the selection performed by the ST author.
Security Target Version 1.0 9/29/2014 distributed when multiple clients connect to the TOE. The evaluator shall also perform the following test: Test 1: The evaluator shall successfully connect multiple clients to the TOE. As the clients are connected, the evaluator shall observe that the GTK is not transmitted in the clear between the client and the TOE. Test 2: The evaluator shall cause a broadcast message to be sent to all clients connected to the TOE.
Security Target Version 1.0 9/29/2014 5.2.2.7 Cryptographic Operation (Cryptographic Signature) (FCS_COP.1(2)) FCS_COP.1.
Security Target Version 1.0 9/29/2014 The evaluator shall use tests from “The Counter with Cipher Block Chaining-Message Authentication Code (CCM) Validation System (CCMVS)” as a guide in testing the requirement above. This will require that the evaluator have a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test. Additionally, the evaluator shall use tests from the IEEE 802.11-02/362r6 document “Proposed Test vectors for IEEE 802.
Security Target Version 1.0 9/29/2014 all statements that are not 'MUST' (for example, 'MAY', 'SHOULD', 'SHOULD NOT', etc.), if the TOE implements such options it shall be described in the TSS.
Security Target Version 1.0 9/29/2014 FCS_IPSEC_EXT.1.4 The TSF shall ensure that [IKEv1 SA lifetimes are able to be limited by number of packets and time: 24 hours for Phase 1 SAs and 8 hours for Phase 2 SAs; IKEv2 SA lifetimes can be configured by an administrator based on number of packets or length of time]. Assurance Activity: If IKEv1 requirements are selected, the evaluator checks to ensure that the TSS describes how lifetimes for IKEv1 SAs (both Phase 1 and Phase 2) are established.
Security Target Version 1.0 9/29/2014 Assurance Activity: The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a particular DH group is specified/negotiated with a peer.
Security Target Version 1.0 9/29/2014 TSS shall also describe the checks that are done when negotiating IKEv1 Phase 2 and/or IKEv2 CHILD_SA suites to ensure that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated algorithm is less than or equal to that of the IKE SA this is protecting the negotiation. The evaluator shall also perform the following tests: Test 1: This test shall be performed for each version of IKE supported by the TOE.
Security Target Version 1.0 9/29/2014 The evaluators shall perform a Variable Seed Test. The evaluators shall provide a set of 128 (Seed, DT) pairs to the TSF RBG function, each 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value is incremented by 1 for each set. The seed values shall have no repeats within the set. The evaluators ensure that the values returned by the TSF match the expected values.
Security Target Version 1.0 9/29/2014 evaluator shall check the operational guidance to ensure that it contains instructions for configuring these values. The evaluator shall also perform the following tests: Test 1: The evaluator shall demonstrate that taking longer than the timeout period to authenticate to the TOE results in a disconnection of the current session and requires that the evaluator initiate a new session to attempt to connect.
Security Target Version 1.0 9/29/2014 may have to be restricted to meet the requirements). The evaluator shall also perform the following test: Test 1: The evaluator shall establish a SSH connection using each of the encryption algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of a protocol to satisfy the intent of the test. FCS_SSH_EXT.1.
Security Target Version 1.0 9/29/2014 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ]. Component Assurance Activity: In order to show that the TSF implements the RFCs correctly, the evaluator shall ensure that the TSS contains the following information: For each section of each applicable RFC listed for the FCS_TLS_EXT.1 elements, for all statements that are not 'MUST' (for example, 'MAY', 'SHOULD', 'SHOULD NOT', etc.
Security Target Version 1.0 9/29/2014 5.2.4 Identification and authentication (FIA) 5.2.4.1 Extended: 802.1X Port Access Entity (Authenticator) Authentication (FIA_8021X_EXT.1) FIA_8021X_EXT.1.1 The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the 'Authenticator' role. FIA_8021X_EXT.1.2 The TSF shall support communications to a RADIUS authentication server conforming to RFCs 2865 and 3579. FIA_8021X_EXT.1.3 The TSF shall ensure that no access to its 802.
Security Target Version 1.0 9/29/2014 Component Assurance Activity: The evaluator shall examine the TSS to determine that it contains a description, for each supported method for remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked. The TSS shall also describe the method by which the remote administrator is prevented from successfully logging on to the TOE, and the actions necessary to restore this ability.
Security Target Version 1.0 9/29/2014 specified in the requirement. The evaluator shall then, for each set of rules, compose passwords that both meet the requirements, and fail to meet the requirements, in some way. For each password, the evaluator shall verify that the composition rules are enforced.
Security Target Version 1.0 9/29/2014 repeat Test 1 using the minimum length; the maximum length; and an invalid length. The minimum and maximum length tests should be successful, and the invalid length must be rejected by the TOE. Test 3 [conditional]: If the TOE does not generate bit-based pre-shared keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length and enter it according to the instructions in the operational guidance.
Security Target Version 1.0 9/29/2014 5.2.4.8 User Identification and Authentication (FIA_UIA_EXT.1) FIA_UIA_EXT.1.1 The TSF shall allow responses to the following actions prior to requiring the non-TOE entity to initiate the identification and authentication process: Display the warning banner in accordance with FTA_TAB.1; [no other services.] FIA_UIA_EXT.1.
Security Target Version 1.0 9/29/2014 For each section of RFC 5280, any non-conformance to 'MUST' or 'SHOULD' statements shall be described; Any TOE-specific extensions or processing that is not included in the standard that may impact the security requirements the TOE is to enforce shall be described.
Security Target Version 1.0 9/29/2014 Component Assurance Activity: Since administrative functions manipulate the TSF data, the analysis performed by the evaluators in the Assurance Activity for FMT_MOF.1 will demonstrate that this requirement is met. 5.2.5.3 Management of TSF Data (Reading of Authentication Data) (FMT_MTD.1(2)) FMT_MTD.1.1(2) Refinement: The TSF shall prevent reading of the password-based authentication data.
Security Target Version 1.0 9/29/2014 ability to remotely administer the TOE remotely from a wireless client shall be disabled by default; are satisfied. Component Assurance Activity: The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration.
Security Target Version 1.0 9/29/2014 Test 2: The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext. Test 3: The evaluator shall ensure, for each method of communication, modification of the channel data is detected by the TOE.\par\line Further assurance activities are associated with the specific protocols. 5.2.6.3 Replay Detection (FPT_RPL.1) FPT_RPL.1.1 The TSF shall detect replay for the following entities: [network packets terminated at the TOE].
Security Target Version 1.0 9/29/2014 the product. The evaluator obtains a legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE. Then, the evaluator performs a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update.
Security Target Version 1.0 9/29/2014 Component Assurance Activity: The evaluator shall perform the following test: Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the operational guidance to exit or log off the session and observes that the session has been terminated. Test 2: The evaluator initiates an interactive remote session with the TOE.
Security Target Version 1.0 9/29/2014 based on a specific value of the attribute. The evaluator shall then attempt to establish a session in contravention to the attribute setting (for instance, the location is denied based upon the client’s IP address). The evaluator shall observe that the access attempt fails. 5.2.9 Trusted path/channels (FTP) 5.2.9.1 Inter-TSF trusted channel (FTP_ITC.1) FTP_ITC.1.1 Refinement: The TSF shall use 802.
Security Target Version 1.0 9/29/2014 FTP_TRP.1.2 Refinement: The TSF shall permit remote administrators to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial administrator authentication and all remote administration actions. Component Assurance Activity: The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected.
Security Target Version 1.0 9/29/2014 5.3.1 Development (ADV) 5.3.1.1 Basic functional specification (ADV_FSP.1) ADV_FSP.1.1d The developer shall provide a functional specification. ADV_FSP.1.2d The developer shall provide a tracing from the functional specification to the SFRs. ADV_FSP.1.1c The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.
Security Target Version 1.0 9/29/2014 operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6c The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST. AGD_OPE.1.7c The operational user guidance shall be clear and reasonable. AGD_OPE.1.
Security Target Version 1.0 9/29/2014 Appendix C and the assurance activities associated with those requirements provide details on the guidance necessary for both the TOE and operational environment. As indicated in the introductory material, administration of the TOE is performed by administrator role. At a high level, the guidance must contain the appropriate instructions to allow local and remote authenticated administrator access. 5.3.3 Life-cycle support (ALC) 5.3.3.1 Labelling of the TOE (ALC_CMC.
Security Target Version 1.0 9/29/2014 ATE_IND.1.2e The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. Component Assurance Activity: The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the body of this PP’s Assurance Activities.
Security Target Version 1.0 9/29/2014 determine the vulnerabilities that have been found in WLAN Access System products in general, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable.
Security Target Version 1.0 9/29/2014 6. TOE Summary Specification This chapter describes the security functions: • Security audit • Cryptographic support • User data protection • Identification and authentication • Security management • Protection of the TSF • Resource utilisation • TOE access • Trusted path/channels Note that some Assurance Activities require information about design and implementation choices made in regard to RFCs.
Security Target Version 1.0 9/29/2014 interface (part of operating environment) to read audit logs. Though not required by PP, the TOE also stores audit records locally and provides CLI and WebUI capabilities to view the contents of the audit trail. The local cache for audit data is 3*(3*31768 bytes). Since this local protected log storage is FIFO (First in, First out), audit logs are overwritten when the storage is exhausted.
Security Target Version 1.0 9/29/2014 indicate such a failure. An administrator must take action to manually re-synchronize the remote audit log after the path is restored. 6.2 Cryptographic support The TOE meets FIPS 140-2 requirements by allowing the administrator to enable a FIPS operating mode. The CC evaluated configuration of the TOE requires the use of this FIPS operating mode. In this mode, only FIPS-approved algorithms are allowed for cryptographic services (e.g.
Security Target Version 1.
Security Target NIST SP800-56B Section Reference 6.5.1 6.5.2 6.5.2.1 6.6 7.1.2 7.2.1.3 7.2.1.3 7.2.2.3 7.2.2.3 7.2.2.3 7.2.2.3 7.2.2.3 7.2.2.3 7.2.3.3 7.2.3.3 7.2.3.3 7.2.3.3 7.2.3.3 7.2.3.3 8 8.3.2 Version 1.
Security Target Version 1.0 9/29/2014 DRBG Key SP800-90a (256 bits) Generated per SP80090A Stored in plaintext in volatile memory. Zeroized on reboot. DRBG DRBG V SP800-90a (128 bits) Generated per SP80090A Stored in plaintext in volatile memory. Zeroized on reboot. DRBG RNG seed FIPS 186-2 RNG Seed (512 bits) Derived using NONFIPS approved HW RNG Stored in plaintext in volatile memory. Zeroized on reboot.
Security Target Version 1.0 9/29/2014 EC DiffieHellman shared secret Elliptic Curve Diffie-Hellman ( P-256 and P-384) Established during EC Diffie-Hellman Exchange Stored in plaintext in volatile memory. Zeroized when session is closed. Key agreement in IKEv1/IKEv2 RADIUS server shared secret 8-128 character shared secret CO configured Stored encrypted in Flash with the KEK. Zeroized by changing (updating) the preshared key through the User interface.
Security Target Version 1.0 9/29/2014 IPSec session encryption keys Triple-DES (168 bits / AES (128/196/256 bits) Established during the IPSec service implementation Stored in plaintext in volatile memory. Zeroized when the session is closed. Secure IPSec traffic IPSec session authentication keys HMAC-SHA-1 (160 bits) Established during the IPSec service implementation Stored in plaintext in volatile memory. Zeroized when the session is closed.
Security Target Version 1.0 9/29/2014 ECDSA Private Key ECDSA suite B P-256 and P-384 curves Generated in the module Stored in flash memory encrypted with KEK. Zeroized by the CO command write erase all. Used by TLS and EAP-TLS/PEAP protocols during the handshake. ECDSA Public Key ECDSA suite B P-256 and P-384 curves Generated in the module Stored in flash memory encrypted with KEK. Zeroized by the CO command write erase all. Used by TLS and EAP-TLS/PEAP protocols during the handshake. 802.
Security Target Version 1.0 9/29/2014 The supporting cryptographic functions are included to support the HTTPS/TLS (RFCs 2818 TLS 1.0 (RFC 2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246), SSHv2 (RFCs 4251, 4252, 4253, and 4254), and IPsec (RFC 4303) secure communication protocol.
Security Target Version 1.0 9/29/2014 • FCS_CKM.1(1): See table above. • FCS_CKM.1(2): See table above. • FCS_CKM.2(1): See table above. • FCS_CKM.2(2): See table above. • FCS_CKM_EXT.4: Keys are zeroized when they are no longer needed by the TOE • FCS_COP.1(1): See table above. • FCS_COP.1(2): See table above. • FCS_COP.1(3): See table above. • FCS_COP.1(4): See table above. • FCS_COP.1(5): See table above. • FCS_HTTPS_EXT.
Security Target Version 1.0 9/29/2014 account in the internal database and assign a predefined role to that account. User log in to the Controller are restricted based on their assigned role. In this case, the authentication mechanism is provided by the TOE and the credentials are maintained in the internal database. The administrator can also configure the TOE so that wireless users are authenticated using an external authentication server 9. The TOE supports the RADIUS, LDAP, and TACACS+ servers.
Security Target Version 1.0 9/29/2014 interoperability testing through custom-built automated test beds which contain numerous client operating systems (Windows XP, Windows Vista, Windows 7, Windows 8, Mac OS X, Linux, Apple iOS, Android, etc.) connecting to Aruba Wi-Fi access points. Finally, the products are Wi-Fi certified by the Wi-Fi Alliance – conformance with 802.1X and EAP/RADIUS are requirements to pass these tests.
Security Target Version 1.0 9/29/2014 into the controller using the “Certificate Manager” section of the Web-based user interface. The controller supports loading of certificates in PEM, DER, or PFX format. Private keys may be loaded onto the controller through a password-protected PFX file, or may originate on the controller at the time a Certificate Signing Request (CSR) is generated. • During runtime, certificates and private keys are stored in ramdisk, in volatile memory, in decrypted form.
Security Target Version 1.0 9/29/2014 • FMT_MTD.1(2): The TOE provides no interfaces that allow user passwords to be read. Passwords are not stored in plaintext. They are stored on flash using a SHA1 hash. They are used for administrative authentication. Wireless user passwords are found in an external AAA/RADIUS server. • FMT_MTD.1(3): The TOE provides no interfaces that allow pre-shared, symmetric, or private keys to be read. • FMT_SMF.
Security Target Version 1.0 9/29/2014 CPU and electronic fuses are blown to protect it from overwrite. On bootup, the controller performs a SHA1 hash of the ArubaOS image file, then compares it to the digital signature. The digital signature is checked against the root CA certificate.
Security Target • Monitoring > Controller > Clients • Monitoring > WLAN > [ESSID_NAME] > Access Points • Monitoring > WLAN > [ESSID_NAME] > Clients • Monitoring > Debug > Local Clients • Monitoring > Debug > Process Logs • Maintenance > WLAN > Program AP • Maintenance > WLAN > Reboot AP Version 1.0 9/29/2014 The TOE assesses wireless user inactivity as the cessation of network traffic arriving from the wireless client.
Security Target Version 1.0 9/29/2014 The TOE uses the IPsec/IKE protocol with pre-shared keys or certificates to establish a trusted channel between itself and the external authentication, logging, and NTP servers. To configure the channels the administrator uses the Security -> Advanced -> VPN panel of the Web GUI to create the host-to-host IPsec/IKE connections. All configuration settings must specify FIPS-certified encryption algorithms as specified by the FCP_COP.1 requirements.
Security Target Version 1.0 9/29/2014 7. Protection Profile Claims The ST conforms to the Protection Profile for Wireless Local Area Network (WLAN) Access Systems, version 1.0, 01 December 2011 (WLASPP). As explained previously, the security problem definition, security objectives, and security requirements have been drawn verbatim from the WLASPP.
Security Target Version 1.0 9/29/2014 8. Rationale This section provides the rationale for completeness and consistency of the Security Target. The rationale addresses the following areas: • Security Objectives; • Security Functional Requirements; • Security Assurance Requirements; • Requirement Dependencies; • TOE Summary Specification. 8.
Security Target Version 1.0 9/29/2014 8.1.1.1 P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE. This Organizational Policy is satisfied by ensuring that: • O.DISPLAY_BANNER: Satisfies this policy by ensuring that the TOE displays an Authorized Administrator configurable banner that provides all users with a warning about the unauthorized use of the TOE. 8.1.1.2 P.
Security Target Version 1.0 9/29/2014 8.1.1.6 T.ADMIN_ERROR An administrator may unintentionally install or configure the TOE incorrectly, resulting in ineffective security mechanisms. This Threat is satisfied by ensuring that: • O.TOE_ADMINISTRATION: Plays a role in mitigating this threat by limiting the functions an administrator can perform. Revoking administrator access when not needed also reduces the chance that an error may occur. • OE.
Security Target • • Version 1.0 9/29/2014 O.TOE_ADMINISTRATION: Requires the TOE to provide mechanisms (e.g., local authentication, remote authentication, means to configure and manage the TOE both remotely and locally) that allow remote and local administration of the TOE. O.WIRELESS_CLIENT_ACCESS: Mitigates the threat by providing mechanisms to restrict wireless client access according to the desired security posture of the TOE. 8.1.1.10 T.
Security Target Version 1.0 9/29/2014 intruders into the TOE environment, but it does not include physical destructive actions that might be taken by an individual that is authorized to access the TOE environment. 8.1.1.16 A.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. This Assumption is satisfied by ensuring that: • OE.
X X O.WIRELESS_CLIENT_ACCESS O.VERIFIABLE_UPDATES O.TSF_SELF_TEST O.TOE_ADMINISTRATION O.TIME_STAMPS O.SYSTEM_MONITORING O.SESSION_LOCK O.ROBUST_TOE_ACCESS O.RESOURCE_AVAILABILITY X O.RESIDUAL_INFORMATION_CLEARING X O.REPLAY_DETECTION O.PROTOCOLS O.FAIL_SECURE O.DISPLAY_BANNER X O.PROTECTED_COMMUNICATIONS FIA_8021X_EXT.1 FIA_AFL.1 FIA_PMG_EXT.1 FIA_PSK_EXT.1 FIA_UAU.6 FIA_UAU.7 FIA_UAU_EXT.5 FIA_UIA_EXT.1 FIA_X509_EXT.1 FMT_MOF.1 FMT_MTD.1(1) FMT_MTD.1(2) FMT_MTD.1(3) FMT_SMF.1 FMT_SMR.
Security Target • • • • • • • Version 1.0 9/29/2014 FCS_IPSEC_EXT.1: Requires the TOE provide a mechanism that creates a distinct communication channel between the TOE and both remote administrators and trusted IT entities that protects the data that traverse this channel from disclosure or modification. FCS_SSH_EXT.
Security Target Version 1.0 9/29/2014 8.2.1.3 O.DISPLAY_BANNER The TOE will display an advisory warning regarding use of the TOE. This TOE Security Objective is satisfied by ensuring that: • FTA_TAB.1: Requires the TOE to display an administrator defined banner before a user can establish an authenticated session. This banner is under complete control of Authorized Administrators in which they specify any warnings regarding unauthorized use of the TOE. 8.2.1.4 O.
Security Target • • • • • • Version 1.0 9/29/2014 FCS_HTTPS_EXT.1: References the applicable standards (and indicates any restrictions on those standards) applicable to the protocol they require to be implemented. FCS_IPSEC_EXT.1: References the applicable standards (and indicates any restrictions on those standards) applicable to the protocol they require to be implemented. FCS_SSH_EXT.
Security Target • • • • • • • Version 1.0 9/29/2014 FIA_UAU.7: Ensures that authentication feedback is obscured at the local console. FIA_UAU_EXT.5: Requires that the TSF provides local authentication methods (one of which is required to be a local password-based mechanism, with other optional (potentially off-box) mechanisms allowed) to ensure that unauthorized users cannot gain logical access to the TOE. FIA_UIA_EXT.
Security Target Version 1.0 9/29/2014 8.2.1.13 O.TIME_STAMPS The TOE shall provide reliable time stamps and the capability for the administrator to set the time used for these timestamps. This TOE Security Objective is satisfied by ensuring that: • FPT_STM.1: Requires that the TOE be able to provide reliable time stamps for its own use and therefore, partially satisfies this objective.
Security Target Version 1.0 9/29/2014 This TOE Security Objective is satisfied by ensuring that: • FTA_TSE.1: Provides the capability to control access by wireless clients based on time of day, their location (e.g., IP address), and other attributes that may be implemented by the TOE. 8.3 Security Assurance Requirements Rationale The Security Assurance Requirements (SARs), which correspond to EAL1, in this ST represent the SARs identified in the WLASPP.
Security Target Version 1.0 9/29/2014 ST Requirement FPT_FLS.1 FPT_ITT.1 FPT_RPL.1 FPT_STM.1 FPT_TST_EXT.1 FPT_TUD_EXT.1 FRU_RSA.1 FTA_SSL.3 FTA_SSL.4 FTA_SSL_EXT.1 FTA_TAB.1 FTA_TSE.1 FTP_ITC.1 FTP_TRP.1 ADV_FSP.1 AGD_OPE.1 AGD_PRE.1 ALC_CMC.1 ALC_CMS.1 ATE_IND.1 CC Dependencies none none none none none none none none none none none none none none none ADV_FSP.1 none ALC_CMS.1 none ADV_FSP.1 and AGD_OPE.1 and AGD_PRE.1 AVA_VAN.1 ADV_FSP.1 and AGD_OPE.1 and AGD_PRE.
FCS_CKM.2(1) FCS_CKM.2(2) FCS_CKM_EXT.4 FCS_COP.1(1) FCS_COP.1(2) FCS_COP.1(3) FCS_COP.1(4) FCS_COP.1(5) FCS_HTTPS_EXT.1 FCS_IPSEC_EXT.1 FCS_RBG_EXT.1 FCS_SSH_EXT.1 FCS_TLS_EXT.1 FDP_RIP.2 FIA_8021X_EXT.1 FIA_AFL.1 FIA_PMG_EXT.1 FIA_PSK_EXT.1 FIA_UAU.6 FIA_UAU.7 FIA_UAU_EXT.5 FIA_UIA_EXT.1 FIA_X509_EXT.1 FMT_MOF.1 FMT_MTD.1(1) FMT_MTD.1(2) FMT_MTD.1(3) FMT_SMF.1 FMT_SMR.1 FPT_FLS.1 FPT_ITT.1 FPT_RPL.1 FPT_STM.1 FPT_TST_EXT.1 FPT_TUD_EXT.1 FRU_RSA.1 FTA_SSL.3 FTA_SSL.4 FTA_SSL_EXT.1 FTA_TAB.1 FTA_TSE.
