_CP_CampusWLAN_v3.1.0_d28Jan25.pdf

COMMERCIAL SOLUTIONS for CLASSIFIED

(CSfC)

Campus Wireless Local Area Network (WLAN)

Capability Package V3.1

Version 3.1

28 January 2025 i

CHANGE HISTORY

Title Version Date Change Summary

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area Network (WLAN) Capability Package

3.1 28 January 2024 Added Composed EUD Requirement

Added Clarification on Gray Management and Gray Data Network Separation

Removed duplicate rational for layered encryption title

Aligned Two Factor Authentication to Multi-Factor Authentication requirements

Added Dedicated Outer WLAN use case

Added objective requirement for Beacon Protection and Operation Channel Validation

Added SHA-512 support

WLAN-WC-6 has been moved to objective

Alternative made for WLAN-EU-29 to allow for administrator lock out instead of device wipe

DTLS has been added to WLAN-WL-4

Added allowance for EUD to be directly wired into Red Network in WLAN-EU-17

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area Network (WLAN) Capability Package

3.0 04 May 2022 Updated to WPA3 standard for 802.11 encryption, deprecating WPA2 in this document.

Added Campus WLAN Tactical Appendix.

Added Objective Virtualization requirements.

Added Objective Two Factor requirements.

Rewrote sections for consistency with other CSfC CPs.

Added inner firewall requirement.

Increased EUD minimum password to 14 characters.

Added 802.11w requirement.

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area Network (WLAN) Capability Package

2.3 April 2021 Relocated WIDS Requirements from the CP

and created a separate WIDS/WIPS Annex.

Relocated Continuous Monitoring Requirements from the CP and created a separate Continuous Monitoring Annex.

Inner Encryption Component must function using Tunnel Requirement.

ii

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area Network (WLAN) Capability Package

2.2 June 26, 2018 Relocated Key Management Requirements

from the CP and created a separate Key Management Requirements Annex.

Updated requirements to use “must” instead of “shall.”

Minor administrative changes were made in formatting.

Changed WLAN PS-12 to ‘Objective.’

Changed WLAN PS-14 to ‘Threshold=Objective.’

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area Network (WLAN) Capability Package

2.1 February 2018 Removed references to CNSS AM 02-15 as

CNSSP-15 was updated and signed.

Removed references to Suite-B encryption algorithms. Updated to reference the Commercial National Security Algorithm (CNSA) Suite.

Changed WLAN-PS-9 to Objective.

Changed WLAN-EU-23 minimum password length.

Updated Continuous Monitoring section to be consistent with other DIT CPs.

Updated Testing Requirements and created a Testing Requirements Annex.

Updated template IAD -> IAC.

Added requirement WLAN-PS-6 for selecting a Certification Authority from the CSfC Components list.

Removed Threat section—in a separate document available on the CSfC webpage.

Modified Table 9 to change the Objective requirement for AES-256-GCMP to AES- 256-CCMP; removed inaccurate RFC references.

Added wording (from the Mobile Access CP) at the end of Section 2 to address case-by-case approvals for TS systems.

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area Network (WLAN) Capability Package

2.0 March 18, 2016 Added EUD requirement (WLAN-EU-40) to

isolate the management and control of the EUD connection to the WLAN system from other EUD functions.

Added IDS requirements for the Gray Network.

Commercial Solutions for Classified (CSfC) Campus Wireless Local Area

1.8 September 17, Initial release of CSfC Campus WLAN guidance for use of a Shared Outer WPA2 layer and single Gray Network with iii

Network (WLAN) Capability Package networks of multiple security levels.

Improvements of Continuous Monitoring and revised content to be consistent with VPN CP version 3.2 and MA CP version 1.1.

Added new Cryptography standards in accordance with CNSSP 15.

Added Gray Firewall.

Added Continuous Monitoring Requirements

Updated requirement WLAN-PS-10

Commercial Solutions for Classified (CSfC) Campus IEEE 802.11 Wireless Local Area Network (WLAN) Capability Package

1.1 March 4, 2014 Corrected minor errors.

Removed redundant requirements.

Added Solution testing section.

Added Appendix F to state summary of changes in requirements between the versions.

Commercial Solutions for Classified (CSfC) Campus IEEE 802.11 Wireless Local Area Network (WLAN) Capability Package

1.0 August 20, 2013 Official release of CSfC Campus WLAN

guidance.

Revised content to be consistent with VPN CP version 2.0.

Removed compound requirements for improved testability.

Merged sections to reduce duplicate requirements.

iv

TABLE OF CONTENTS

1 Introduction

2 Purpose and Use

3 Legal Disclaimer

4 Description of the Campus WLAN Solution

4.1 Rationale for Layered Encryption

4.2 Networks

4.2.1 Red Network

4.2.2 Gray Network

4.2.3 Black Network

4.2.4 Data, Management, and Control Plane Traffic

4.3 High-Level Design

4.3.1 End User Devices

4.3.2 Multiple Security Levels

4.4 Authentication

4.4.1 Traditional Authentication

4.4.2 Multi-Factor Authentication

4.5 Other Protocols

4.6 Availability

4.7 Implementing CSfC in a High Assurance GOTS Environment

5 Infrastructure Components

5.1 WLAN Access System

5.2 Gray Firewall

5.3 Inner Firewall

5.4 Gray Management Services

5.4.1 Gray Administration Workstation

5.4.2 Gray Security Information and Event Management (SIEM)

5.4.3 Gray Authentication Server

5.5 Inner Encryption Components

5.5.1 Inner VPN Gateway

5.6 Red Management Services

v

5.6.1 Red Administration Workstations

5.6.2 Red Security Information and Event Management (SIEM)

5.7 Public Key Infrastructure Components

6 End User Device Components

6.1 EUD Hardware Platform

6.2 Dedicated Security Component

6.3 Operating System

6.4 WLAN Client

6.5 Dedicated Outer WLAN

6.6 VPN Client

6.7 Hypervisor

6.8 End User Devices Full Disk Encryption

6.9 MDF End User Device

6.10 Composed End User Device Components

6.10.1 Virtualized EUD

6.11 Hardware Separated EUDs

6.11.1 Dedicated Outer WLAN (Outer Wireless Access)

6.11.2 Dedicated Inner VPN (Inner Encryption Component)

6.12 Red Compute Hardware

7 End User Device Deployments

7.1 End User DiT Options

7.2 End User Device Handling Options

7.2.1 Multi-Factor Authentication Options

8 Campus WLAN Configuration and Management

8.1 Solution Infrastructure Component Provisioning

8.2 EUD Provisioning

8.3 Management of Campus WLAN Solution Components

8.4 EUDs for Different Classification Domains

9 Continuous Monitoring

9.1 Wireless Intrusion Detection System (WIDS)

10 Key Management vi

11 Requirements Overview

11.1 Threshold and Objective Requirements

11.2 Requirements Designators

12 Requirements for Selecting Components

13 Configuration Requirements

13.1 Overall Solution Requirements

13.2 End User Device Requirements

13.3 Enhanced Virtualization Requirements

13.4 WLAN Client Configuration Requirements

13.5 VPN Components and VPN Client Configuration Requirements

13.6 WLAN Access System Configuration Requirements

13.7 Port Filtering Requirements

13.8 End User Device Provisioning Requirements

13.9 Configuration Requirements for Wireless Intrusion Detection System (WIDS)

13.10 Configuration Change Detection Requirements

13.11 Device Management Requirements

13.12 Continuous Monitoring Requirements

13.13 Auditing Requirements

13.14 Key Management Requirements

13.15 Gray Firewall Requirements

13.16 Multi-Factor Authentication Requirements

14 Requirements for Solution Operation, Mainteniance, and Handling

14.1 Use and Handling of Solutions (GD) Requirements

14.2 Requirements for Incident Reporting

15 Role-Based Personnel Requirements

16 Information to Support AO

16.1 Solution Testing

16.2 Risk Assessment

16.3 Registration of Solutions

Appendix A. Glossary of Terms

Appendix B. Acronyms vii

Appendix C. References

Appendix D. Tactical Solution Implementations

Appendix E. EUD Type Guidance viii

Table of Figures

Figure 1. Overview of Campus WLAN CP

Figure 2. Gray Data and Management VRF Separation

Figure 3. Campus WLAN Single Classification Implementation

Figure 4. Campus WLAN Solution for Two Networks of the Same Classification Level

Figure 5. Campus WLAN Solution for Networks Operating at Different Classification Levels

Figure 6. Overview of Gray Management Services

Figure 7. Overview of Red Management Services

Figure 8. General Purpose Computing Platform

Figure 9 . Dedicated Security Component

Figure 10. Dedicated Security Component

Figure 11. Virtualization Client

Figure 12. Campus WLAN MFD EUD Architecture

Figure 13. Campus WLAN Composed EUD Architecture

Figure 14. Enhanced Software Virtualization Architecture

Figure 15. VM Interconnectivity

Figure 16. Dedicated Outer WLAN

Figure 17. Campus WLAN Continuous Monitoring Points ix

List of Tables

Table 1. EUD Type Summarization

Table 2. Composed EUD Sub-Components

Table 3. Virtualized EUD Components

Table 4. Access CDS EUD Components

Table 5. Requirement Digraph

Table 6. Production Selection Requirements

Table 7. Overall Solution Requirements (SR)

Table 8. End User Device (EU) Requirements

Table 9. Enhanced Virtualization Requirements

Table 10. WLAN Client (WC) Configuration Requirements

Table 11. Dedicated Outer WLAN (WO) Requirements

Table 12. Wireless Link (WL) Requirements

Table 13. IPSec Encryption (Approved Algorithms for Classified)

Table 14. WPA3 Encryption and EAP-TLS (Approved Algorithms)

Table 15. VPN Components Configuration Requirements (CR)

Table 16. WLAN Access System (WS) Configuration Requirements

Table 17. Wireless Infrastructure Authentication (IA) Requirements

Table 18. Wireless Authentication and Authorization (AA) Requirements

Table 19. Wireless Authentication Server (WA) Requirements

Table 20. Solution Components Port Filtering (PF) Requirements

Table 21. EUD Provisioning Requirements (PR)

Table 22. WIDS/WIPS Requirements

Table 23. Device Management (DM) Requirements

Table 24. Continuous Monitoring Requirements

Table 25. Key Management Requirements

Table 26. Gray Firewall (FW) Requirements

Table 27. Multi-Factor Authentication Use Case Requirements

Table 28. Use and Handling of Solutions Requirements

Table 29. Incident Reporting Requirements (RP)

Table 30. Role-Based Personnel Requirements

Table 31. Test Requirement x

Table 32. Tactical Implementation Overlay Requirements

Table 33. EUD Type Summarization

1 INTRODUCTION

The Commercial Solutions for Classified (CSfC) program within the National Security Agency (NSA)

Cybersecurity Directorate (CSD) uses a series of Capability Packages (CP) to provide configurations that allow customers to independently implement secure solutions using layered Commercial Off-the-Shelf

(COTS) products. The CPs are vendor-agnostic and provide high-level security and configuration guidance for customers and/or Integrators.

NSA delivers a generic CSfC Campus Wireless Local Area Network (WLAN) CP to meet the demand for commercial End User Devices (EUD) (tablets, smartphones, and laptop computers) to access secure enterprise services over a campus wireless network. Cryptographic algorithms, known as Commercial

National Security Algorithms (CNSA), are used to protect classified data using layers of COTS products.

In WLAN CP Version 3.1, the Continuous Monitoring (CM) and Wireless Intrusion Detection System

(WIDS) Requirements have been relocated from the CP to separate corresponding Annexes.

2 PURPOSE AND USE

This CP provides reference architecture and corresponding configuration information that allows customers to select COTS products from the CSfC Components List for their Campus WLAN solution and then to properly configure those products to achieve a level of assurance sufficient for protecting classified data while in transit. Throughout this CP, requirements imposed on the Campus WLAN solution are identified by a label consisting of the prefix “WLAN,” a two-letter category, and a sequence number (e.g., WLAN-KM-11). To successfully implement a solution based on this CP, all Threshold requirements, or the corresponding Objective requirements, must be implemented as described in

Section 11.1.

Please provide comments on usability, applicability, and/or shortcomings to your NSA/CSD Client

Advocate and the Campus WLAN CP maintenance team at Wi-Fi@nsa.gov.

CNSS Policy No. 15, Use of Public Standards for Secure Information Sharing, identifies additional public algorithms to protect information within NSS. Specifically, the following algorithms will be required to protect all NSS up to Top Secret:

AES 256 (confidentiality)

RSA 3072 or ECDSA P-384 (digital signature and authentication)

RSA 3072, DH 3072 or ECDH P-384 (key exchange)

SHA-384 or SHA-512 (hashing and integrity)

Campus WLAN CP solutions must comply with Committee on National Security Systems, (CNSS) policies and instructions. Any conflicts identified between this CP and NSS or local policy should be provided to the Campus WLAN CP Maintenance team.

Customers and integrators must adhere to all applicable data transfer policies for their organization when designing and implementing Cross Domain Solutions (CDS) capabilities within their CSfC solution architecture. For example, DoD customers must follow DoDI 8540.01, “Cross Domain (SD) Policy”, when file:///C:/Users/bmantho/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/0I5PX5Y4/Wi-Fi@nsa.gov deploying a CDS within a CSfC solution. Any discrepancies found between the guidance in this document and DoDI 8540.01 should be reported to the CSfC PMO office at csfc@nsa.gov.

For any additional information on CDSs, contact the National Cross Domain Strategy Management Office (NCDSMO) at ncdsmo@nsa.gov.

3 LEGAL DISCLAIMER

This CP is provided “as is.” Any express or implied warranties, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event must the

United States Government be liable for any direct, indirect, incidental, special, exemplary or consequential damages (including, but not limited to, procurement of substitute goods or services, loss of use, data, or profits, or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this CP, even if advised of the possibility of such damage.

The user of this CP agrees to hold harmless and indemnify the United States Government, its agents and employees from every claim or liability (whether in tort or in contract), including attorney’s fees, court costs, and expenses, arising in direct consequence of Recipient’s use of the item, including, but not limited to, claims or liabilities made for injury to or death of personnel of User or third parties, damage to, or destruction of, property of User or third parties, and infringement or other violations of intellectual property or technical data rights.

Nothing in this CP is intended to constitute an endorsement, explicit or implied, by the U.S. Government of any particular manufacturer’s product or service.

4 DESCRIPTION OF THE CAMPUS WLAN SOLUTION

The solution described within this CP is supported by the use of wireless devices to access sensitive data and enterprise services while minimizing the risk when connecting to existing Government enterprise networks. Government-managed campus-area wireless networks provide controlled connectivity between mobile users and the broader Government enterprise. The term “Campus” is used in this document to refer to any area that is physically protected to the highest classification level of the enterprise network where multiple enclaves are supported. This physical area includes secure facilities and tactical environments when the Authorizing Official (AO) deems the physical controls appropriate.

The Campus WLAN solution uses two layers of cryptography, Internet Protocol Security (IPsec) using AES

256 and WPA3 using AES 256, to protect the confidentiality and integrity of the data as it transits the untrusted network. The Virtual Private Network (VPN) Client and WLAN Client running on an EUD generate the two layers protecting data flow. Figure 1 shows at a high level the basic segments of the

Campus WLAN architecture. A customer implementing a WLAN solution that uses two layers of IPsec encryption has the option of complying and registering with the latest Mobile Access CP instead of this mailto:csfc@nsa.gov mailto:ncdsmo@nsa.gov

CP.

Figure 1. Overview of Campus WLAN CP

Campus WLAN solutions are composed, layered, and built using products from the CSfC Components

List. Customers who are concerned that their desired products are not yet on the CSfC Components List are encouraged to contact the vendors and urge them to sign a Memorandum of Agreement (MOA) with NSA and start the National Information Assurance Partnership (NIAP) evaluation process, which enables them to be listed on the CSfC Components List. Products listed on the CSfC Components List are not guaranteed to be interoperable with all other products on the Components List. Customers and

Integrators should perform interoperability testing to ensure the components selected for their Campus

WLAN solution are interoperable. Customers needing assistance obtaining vendor POC information should email csfc_components@nsa.gov.

While CSfC encourages industry innovation, trustworthiness of the components is paramount.

Customers and their Integrators are advised that modifying a NIAP-evaluated component in a CSfC solution may invalidate its certification and trigger a revalidation process. To avoid delays, customers or

Integrators who feel it is necessary to modify a component should engage the component vendor and consult NIAP through their Assurance Continuity Process (see http://www.niap-ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-6.pdf) to determine whether such a modification will affect the component’s certification. If a component is modified, NSA’s CSfC PMO

Office requires a statement from NIAP that the modification does not alter the certification or security of the component. Modifications which trigger the revalidation process include, but are not limited to the following: modifying the original equipment manufacturers’ code (to include digitally signing the code) or not leveraging the baseline NIAP-evaluated configuration.

4.1 RATIONALE FOR LAYERED ENCRYPTION

A single layer of CNSA encryption, properly implemented, is sufficient to protect classified data in transit. However, a CSfC Campus WLAN solution uses two layers of CNSA encryption to mitigate the risk of a failure in one of the cryptographic components. Accidental misconfiguration, operator error, or malicious exploitation of a vulnerability, could result in the exposure of classified information if a single file:///C:/Users/bmantho/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/0I5PX5Y4/csfc_components@nsa.gov http://www.niap-ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-6.pdf http://www.niap-ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-6.pdf layer is used. The use of multiple layers, implemented with components meeting the CSfC vendor diversity requirements, reduces the likelihood that a single vulnerability can be exploited to reveal protected information.

Diversity of implementation is needed between the components in each layer of the solution in order to reduce the likelihood that both layers share a common vulnerability. The CSfC Program recognizes two ways to achieve this diversity. The first is to implement each layer using components produced by different manufacturers. The second is to use components from the same manufacturer, where the manufacturer has provided NSA with sufficient evidence that the implementations of the two components are independent of one another. The CSfC web page

(https://www.nsa.gov/resources/commercial-solutions-for-classified-program) contains details on how a manufacturer submits this evidence to NSA and what documentation must be provided. Customers that wish to use products from the same manufacturer in both layers must contact their NSA Client

Advocate to confirm that NSA has accepted the manufacturer’s claims before implementing their solution.

4.2 NETWORKS

This CP uses the following terminology to describe the various networks that comprise a Campus WLAN solution and the types of traffic present on each. The terms Red, Gray, and Black refer to the level of protection applied to the data as described below.

4.2.1 RED NETWORK

Red data consists of unencrypted classified data and a Red Network contains only Red data. Red

Networks are under the control of the solution owner or a trusted third party.

The Red Network begins at the internal interface(s) of Inner Encryption Components located between the Gray Firewall and Inner Firewall. EUDs access the Red Network through the two layers of nested encryption described in this CP. For example, an Inner VPN Gateway located between the Gray Firewall and Inner Firewall terminates the Inner layer of IPsec encryption from a VPN EUD. Once a successful

IPsec connection is established, the EUD is given access to classified services such as web, email, Virtual

Desktop Infrastructure (VDI), voice, etc.

Red Networks may only communicate with an EUD through the WLAN solution if both operate at the same security level.

4.2.2 GRAY NETWORK

Gray data is classified data that has been encrypted once. Gray Networks are composed of Gray data and Gray Management Services. Gray Networks are under the physical and logical control of the solution owner or a trusted third party.

The Gray Network is physically treated as a classified network even though all classified data is singly encrypted. If a solution owner’s classification authority determines that data on a Gray Network is classified, perhaps by determining the Internet Protocol (IP) addresses are classified at some level, then the WLAN solution described in this CP cannot be implemented, as it is not designed to provide two layers of protection for any data/traffic on the Gray Network.

https://www.nsa.gov/resources/commercial-

Gray Network components consist of the WLAN Access System, Gray Firewall, and Gray Management

Services. All Gray Network components are physically protected at the same level as the Red Network components of the WLAN infrastructure. Gray Management Services are physically connected to the

Gray Firewall and include, at a minimum, an administration workstation. The Gray Management

Services also include a Security Information and Event Management (SIEM) unless the SIEM is implemented in the Red Network in conjunction with a CDS. See the Continuous Monitoring Annex for more information. The WLAN CP requires the management of Gray Network components through the

Gray administration workstation. As a result, neither Red nor Black Administration Workstations are permitted to manage the WLAN Access System, Gray Firewall, or Gray Management Services.

Additionally, the Gray administration workstation is prohibited from managing Inner Encryption

Components. These Inner Encryption Components must be managed from a Red Administration

Workstation.

The Gray Network may be extended and shared through different sites using the Enterprise Gray

Implementation Requirements Annex. This Annex allows for Gray Management Services to be shared between different CSfC deployments. For more information see the Enterprise Gray Implementation

Requirements Annex.

4.2.3 BLACK NETWORK

A Black Network contains classified data that has been encrypted twice. The wireless network between the EUD and the WLAN Access System in which data is protected with two layers of encryption (the

IPsec and the WPA3 layers) is a Black Network. Depending on which vendor product is chosen from the

CSfC Components List, the WPA3 layer can terminate on either the Access Point(s) (AP) or Wireless controller. For WPA3 tunnels terminating at the AP, encryption standards such as IPsec, Secure Shell version 2 (SSHv2), Transport Layer Security (TLS), or TLS/ Hypertext Transfer Protocol Secure (HTTPS) must be used to encrypt data between the AP and the wireless controller.

4.2.4 DATA, MANAGEMENT, AND CONTROL PLANE TRAFFIC

Data plane traffic is encrypted or unencrypted classified information that is being passed through the

Campus WLAN solution. The Campus WLAN solution exists to encrypt and decrypt data plane traffic. All data plane traffic within the Black Network must be encapsulated within the Encapsulating Security

Payload (ESP) protocol and WPA3 Enterprise.

Management plane traffic is used to configure and monitor solution components. It includes the communications between a system administrator and a component, as well as the logs and other status information forwarded from a solution component to a log server, SIEM or similar repository.

Management plane traffic on Red and Gray Networks must be encapsulated within the SSHv2, ESP, or

TLS protocol.

Control plane traffic consists of standard protocols necessary for the network to function. Control plane traffic is typically not initiated directly on behalf of a user (unlike data traffic) or a system administrator

(unlike management traffic). Many, but not all, control plane protocols operate at Layer 2 or Layer 3 of the Open Systems Interconnection (OSI) model. Examples of control plane traffic include, but are not limited to, the following:

Network address configuration (i.e., Dynamic Host Configuration Protocol (DHCP), Neighbor

Discovery Protocol (NDP), etc.)

Address resolution (i.e., Address Resolution Protocol (ARP), NDP, etc.)

Name resolution (e.g., Domain Name System (DNS))

Time synchronization (i.e., Network Time Protocol (NTP), Precision Time Protocol (PTP), etc.)

Route advertisement (i.e., Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), etc.)

Certificate status distribution (i.e., Online Certificate Status Protocol (OCSP), Hypertext

Transfer Protocol (HTTP) download of Certificate Revocation Lists (CRLs), etc.)

In general, this CP does not impose detailed requirements on control plane traffic, although control plane protocols may be used in order to implement certain requirements. For example, requirements

WLAN-SR-2 and WLAN-SR-3 (see Section 13.1), require that time synchronization be performed, but do not require the use of any particular time synchronization protocol or technique. Notable exceptions are for IPsec session establishment and for certain certificate status distribution scenarios. This CP provides detailed requirements in those cases due to the impact on the security of the solution. Unless otherwise specified in this CP, the usage of specific control plane protocols is left to the Solution Owner to approve, but any control plane protocols not approved by the solution owner should be disabled.

Data plane and management plane traffic is required to be separated from one another using physical, logically (at the Gray Firewall), or cryptographic separation. Use of a Virtual Local Area Network (VLAN) alone is not sufficient to separate data plane and management plane traffic. As a result, a solution may have a Gray Data network and a Gray Management network are separate from one another, where the components on the Gray Management network are used to manage the components on the Gray Data network. The Gray Management network is separated from the Gray Data network via the Gray Firewall and no other component, such as a switch or router, can conduct this separation unless it is a firewall chosen from the CSfC Components list. The Gray Firewall uses an Access Control List (ACL) to ensure that only appropriate Gray Management Services (i.e., administration workstation, SIEM or Network

Time Server) can communicate with the WLAN Access System. The Gray Firewall is also responsible for ensuring that Gray Management Services are only capable of flowing in the appropriate direction. For example, SSH traffic is permitted to initiate from an administration workstation to the WLAN Access

System, but not from the WLAN Access System to any Gray Management Services. Conversely, system log data is permitted from the WLAN Access System to the Gray collection server, but is not permitted from the Gray Management Services to the WLAN Access System. Given that some control plane traffic is necessary for a network to function, there is no general requirement that control plane traffic be similarly separated, unless otherwise specified.

Figure 2. Gray Data and Management VRF Separation

Data and management traffic may be separated using Virtual Routing and Forwarding (VRF) on the Gray

Firewall to enhance network security beyond firewall ACL filtering. VRFs are not required but can greatly increase the security posture within traditional static routing networks. Each interface will be assigned to a VRF that is specifically allowed to interact with its respective network plane (Data Plane or

Management Plane). In some cases, the implementer may need to import or export routes to establish a VPN tunnel on an interface outside of its respective VRF. The primary use case of importing and exporting routes between VRFs is for the importing of the routes destined for the Inner Encryption

Component to travel over its encrypted tunnel. A separate VRF should be used for the local Gray

Management Network allowing for separation and for connecting the Gray Firewall to the local Gray

Management Network.

4.3 HIGH-LEVEL DESIGN

Figure 3. Campus WLAN Single Classification Implementation

Depending on the needs of the customer implementing the solution, the Campus WLAN CSfC solution is adaptable to support multiple capabilities. If a customer does not have to support multiple classified networks, then those elements do not need be included as part of the implementation as seen in Figure

3. The Black/Gray boundary in Figure 3 can be at the Access Point(s) or Controller, depending on the vendor. Similarly, a customer may choose to implement a solution where classified information is protected as it travels over-the-air between a WLAN-enabled EUD and a WLAN infrastructure attached to a wired network of the same classification level. However, any implementation of the Campus WLAN solution must satisfy all of the applicable requirements specified in this CP.

4.3.1 END USER DEVICES

This CP uses the concept of an EUD, which is either a single Computing Device, such as a smart phone, laptop, or tablet, or the combination of a Computing Device and a Dedicated Outer WLAN. The EUD provides two layers of protection for data in transit to access classified data on the Red Network. EUDs are dedicated to a single classification level and can only be used to access a Red Network of the same classification. EUDs must either be selected from the CSfC Components list or be comprised of selected sub-components listed on the CSfC Components list. For more information see section 6.1.

The two options for selecting an EUD within CWLAN from the CSfC Components list are:.

1) be listed as an MDF EUD on the CSfC Components list;

2) select sub-components listed on the CSfC Components list to compose an EUDs.

The customer and/or Trusted Integrator is responsible for selecting and composing these sub-components into a functioning EUD. The CSfC Program does not guarantee the interoperability of the different sub-components. The sub-components that makeup a composed EUD include the following:

General Purpose Operating Systems or

Client Virtualization Systems;

WLAN Clients ;

General Purpose Compute Platform;

Dedicated Security Component (Optional);

Hardware Full Drive Encryption or

Software Full Drive Encryption;

The Campus WLAN CP allows three different deployment options pertaining to the use and handling of an EUD while powered off:

EUD with DAR: To implement Data-at-Rest (DAR) protection on an EUD, the DAR solution must be approved by NSA, either as a tailored solution or compliant with NSA’s Data-at-Rest

CP. Specification of such a DAR solution is outside the scope of this CP, but can be found in the

DAR CP. The NSA requires implementing organizations to define the circumstances in which an EUD is to be considered outside of the continuous physical control of authorized users (i.e., “lost”). AOs will define “continuous physical control” and that definition should align with the intended mission and threat environment for which the solution will be deployed.

Organizations must also define the circumstances in which an EUD that is a part of that organization’s solution is to be considered recovered back into the continuous physical control of authorized users (i.e., “found”).

Classified EUD: The EUD can be used exclusively with physical security measures approved by the AO. EUDs are not subject to special physical handling restrictions beyond those applicable for classified devices since they can rely on the environment they are in for physical protection. If this design option is selected, the EUDs must be treated as classified devices at all times. The EUD i must have a single layer of CSfC approved DAR protection to protect the private keys stored on it from disclosure and to increase the difficulty of tampering with the software and configuration. Continuous physical control of the EUD must be maintained at all times.

Thin EUD: The EUD can be designed to prevent any classified information except for the private keys from being saved to any persistent storage media on the EUD. Possible techniques for implementing this include, but are not limited to: using Virtual Desktop

Infrastructure (VDI) configured to not allow data from the associated Red Network to be saved on the EUD, restricting the user to a non-persistent virtual machine on the EUD, and/or configuring the EUD’s operating system to prevent the user from saving data locally. Since the

EUD does not provide secure local storage for classified data, its user is also prohibited by policy from saving classified data to it. The EUD i must have a single layer of CSfC approved

DAR protection to protect the private keys stored on it from disclosure, and to increase the difficulty of tampering with the software and configuration. Continuous physical control of the

EUD must be maintained at all times.

The intent of a continuous physical control requirement for the WLAN CP is to prevent potential attacks via brief, undetected physical access of an EUD by any adversary. When used and stored within a protected campus environment, the inherent security controls are sufficient to meet this requirement.

When a WLAN EUD is transported or stored outside of the protected campus, a user must maintain continuous physical control of the EUD such that an adversary cannot obtain brief, undetected physical access.

While powered on, an EUD is classified at the same level of the Red Network that it accesses through the Campus WLAN solution, since classified data may be present in volatile memory and/or displayed on screen. With the addition of the DAR CP to a solution a EUD may be treated as unclassified when fully powered off. To mitigate the risk of accidental disclosure of classified information to unauthorized personnel while the EUD is in use, the customer must define and implement an EUD user agreement that specifies the rules of use for the system. The customer must only grant a user access to an EUD after they complete the user agreement and receive training on the use and protection of the EUD.

4.3.2 MULTIPLE SECURITY LEVELS

A single implementation of the WLAN solution may support multiple Red Networks of different security levels. The WLAN solution provides secure connectivity between EUDs and the Red Network of the same security level while preventing EUDs from accessing Red Networks of different security levels. This enables a customer to use the same physical infrastructure to carry traffic from multiple networks.

EUDs operating as part of a Multiple Security Level solution are still dedicated to a single classification level. Although each Red Network still requires its own Inner Encryption Component(s), a site may use a single WLAN Access System in the infrastructure to encrypt and transport traffic that has been encrypted by Inner Encryption Components of varying security levels. As shown in Figure 4, a SECRET

Coalition EUD is only capable of communicating with and authenticating to the Inner Encryption

Components for the – SECRET Coalition network. This EUD does not have any connectivity to the Inner

Encryption Components of the TS or Unclassified networks.

There is no limit to the number of different security levels that a WLAN solution may support.

In all cases, separate CAs and management devices are needed to manage the Inner Encryption

Components and Inner Firewall at each security level. For example, Figure 4 shows an independent site with multiple security levels. Network 1, Network 2, and Network 3 each have their own CA and management devices which prevent EUDs from being able to authenticate with the incorrect network.

In addition to separate Inner Encryption Components and CAs, an authentication server must be used to allow the use of a single Outer Virtual Private Network (VPN) Gateway for multiple security levels. The authentication server resides within the Gray Management network and validates that Outer Tunnel certificates are signed by the Outer Tunnel CA, are still within their validity period, and have not been revoked. The authentication server also parses the certificate for information assigned to a specific inner network (e.g., Organizational Unit (OU) field or policy Object Identifiers (OIDs)) to determine which inner network the EUD is authorized to connect. After successful authentication, the authentication server provides an accept message to the WLAN Access System along with a Vendor-Specific Attribute

(VSA). The WLAN Access System uses the VSA to assign the proper network and firewall rules such that an EUD can only reach the appropriate Inner Encryption Components.

4.3.2.1 Networks Operating at the Same Classification Level

When Red Networks operate at the same classification level but at different security levels, the cryptographic separation provided by the Inner VPN Gateways is sufficient to protect against unintended data flows between security levels. Two Inner VPN Gateways for networks of different security levels will be unable to mutually authenticate with each other because they trust different CAs which do not have a trust relationship with one another. This prevents the establishment of an IPsec tunnel between the two components.

Figure 4. Campus WLAN Solution for Two Networks of the Same Classification Level

4.3.2.2 Networks Operating at Different Classification Levels For Red Networks of different classification levels, the cryptographic separation of their traffic on a Gray

Network (as described in Section 4.3.2.1) is still present. However, because the consequences of an unintended data flow between different classification levels are more severe than one with a single classification level, an additional mechanism is necessary to further guard against such a flow from occurring.

Figure 5. Campus WLAN Solution for Networks Operating at Different Classification

Levels

In this scenario packet filtering is required within Gray Networks as an additional mechanism to prevent data flows between networks of different classification levels. Any physical path through a Gray

Network between multiple Inner VPN Gateways supporting Red Networks of different classification levels must include at least one filtering component. This filtering component restricts the traffic flowing through it based primarily on the Gray Network source and destination addresses. Packets are passed only if the source and destination components are intended to communicate with one another and are dropped otherwise.

When multiple classification levels are used, it is critical to enforce proper IP address assignment and firewall rule sets. The IP address assigned must be unique to that classification level such that the EUD is only able to send and receive traffic to and from their respective VPN Gateway. Proper assignment of

IP address and firewall rule sets is done at both the Authentication Server (AS) and WLAN access system based on either an allowlist or X.509 Certificate.

4.4 AUTHENTICATION

The WLAN solution provides mutual device authentication between WLAN Access System and between

Inner Encryption Components via public key certificates. This CP requires that all authentication certificates issued to WLAN Access System and Inner Encryption Components be Non-Person Entity

(NPE) certificates. In addition, NPE certificates issued to WLAN Access Systems may need to assert the

IP address of the WLAN Access System in either the Common Name field of the certificate Distinguished

Name, or in the Subject Alternative Name certificate extension. The EUD may be required to check the

IP address asserted in the WLAN Access System certificate and ensure it is the same IP address registered in the EUD.

4.4.1 TRADITIONAL AUTHENTICATION

Following the two layers of device authentication, EUDs require the user to authenticate to the network before gaining access to any classified data (e.g., username/password, user certificate). When a device certificate is used, the user must also authenticate to the Red Network before gaining access to any classified data in the same manner as a EUD (e.g., username/password, user certificate). In this latter case, it is recommended that additional access controls, such as allowlists, be implemented in conjunction with the user certificate to control access to Red Network services.

In addition to authentication for the Outer and Inner layer of encryption, the WLAN CP requires user-to-device authentication. This authentication occurs between the user and the Computing Device (which processes Red data) of an EUD. The WLAN CP requires EUD components use a minimum of a 14-character, case-sensitive, alphanumeric password to authenticate to the device. This password can be used both for decrypting the platform encryption as well as for unlocking the screen. EUD components, which are selected from the Mobile Platform section of the CSfC Components List, are able to use a relatively short authentication factor since they use a hardware based root encryption key which is evaluated during the NIAP certification.

4.4.2 MULTI-FACTOR AUTHENTICATION

Within this CP a form of multi-factor authentication should be used for a user to access classified data.

The current multi-factor authentication options are, ‘something you know’ and ‘something you have.’

There are three forms of multi-factor authentication:

User to EUD

User to VPN

User to Virtual Desktop Interface (VDI)

4.5 OTHER PROTOCOLS

Throughout this document, when IP traffic is discussed, it can refer to either IPv4 or IPv6 traffic, unless otherwise specified, as the WLAN solution is agnostic to most named data handling protocols.

Public standards conformant Layer 2 control protocols are allowed as necessary to ensure the operational usability of the network. This CP is agnostic with respect to Layer 2; specifically, it does not require Ethernet. Public standards conformant Layer 3 control protocols may be allowed based on local

AO policy, but the default configuration of this solution is for all Layer 3 control protocols to be disabled.

Red and Gray Network multicast messages and Internet Group Management Protocol (IGMP) or

Multicast Listener Discovery (MLD) may also be allowed, depending on local AO policy.

It is expected that the WLAN solution can be implemented in such a way as to take advantage of standards-based routing protocols that are already being used in the Red Network. For example, networks that currently use Generic Routing Encapsulation (GRE) or Open Shortest Path First (OSPF) protocols can continue to use these in conjunction with the Inner Firewall solution to provide routing as long as the AO approves their use.

Future iterations of this CP will discuss using different wireless standards other than 802.11 Wi-Fi if the standard still implements the WPA3 standard.

4.6 AVAILABILITY

The high-level designs described in Section 4.3 are not designed to automatically provide high availability. Supporting solution implementations for which high availability is important is not a goal of this version of the CP. However, this CP does not prohibit adding redundant components in parallel to allow for component failover or to increase the throughput of the WLAN solution, as long as each redundant component adheres to the requirements of this CP. The CP does not limit the number of

WLAN Access Systems or Inner Encryption Components that can be implemented for high availability in a WLAN Solution.

An AO may additionally desire to have a wired Red Transport option for the EUDs if the WLAN access systems service is degraded, not available or unusable given the existing environment. In these cases the

AO may allow an Ethernet interface on the EUD to be activated to allow for direct connection to the

CSfC Solutions Red Network. The EUD must only be used to connect to the CSfC Solution and not any other network.

4.7 IMPLEMENTING CSFC IN A HIGH ASSURANCE GOTS ENVIRONMENT

Customers have the option to use a blended solution that combines a CSfC solution with a High

Assurance GOTS solution. While CSfC uses two layers of encryption, this is not required with High

Assurance GOTS, where a single layer of encryption is sufficient. For example, a CSfC Campus WLAN solution can be employed in an infrastructure where network High Assurance Internet Protocol

Encryptors (HAIPE) are also being used. The WLAN solution is segmented, and its protection is provided by CSfC, while the protection of the network that the information transits is provided by a High

Assurance GOTS solution. For additional details or questions about this process, please contact the CSfC

PMO office at csfc@nsa.gov.

5 INFRASTRUCTURE COMPONENTS

In the high-level design discussed in the previous section, at least two layers of encryption, implemented using WPA3 and an Inner layer of IPsec encryption, protect all communications flowing across a Black

Network. Mandatory aspects of the solution infrastructure also include administration workstations, IDS/IPS, SIEM, firewalls, and CAs for key management using PKI.

Each infrastructure component is described in more detail below. The descriptions include information about the security provided by the components as evidence for why they are deemed necessary for the solution. Components are selected from the CSfC Components List and configured per NIAP configuration guidance in accordance with the Product Selection requirements of this CP (see Section

12).

Section 12 also provides details on additional components that can be added to the solution to help reduce the overall risk. Where indicated in the text, these are not considered mandatory components for the security of the solution; therefore, this CP does not place configuration requirements on those optional components.

5.1 WLAN ACCESS SYSTEM

In the context of this solution, the AP and the WLAN Controller, compose the “WLAN Access System.”

These components are grouped together in this document to maintain vendor neutrality; there are a variety of WLAN Access System implementations across the vendor community. The WLAN Access

System must be configured to use WPA3 Enterprise 192-bit mode, using AES 256, for CNSA compliance.

An AP is the media converter providing a link between the WLAN Client and the WLAN Controller. The level of functionality contained within the APs is vendor-dependent. Some solutions use “smart” or

“thick” APs that incorporate a significant amount of functionality, including cryptographic operations. In this case, the APs would be considered part of the Gray Network. Other solutions implement “thin” APs that merely perform the wireless/wired media conversion and push all functionality to the WLAN

Controller. In this case, the APs would be considered part of the Black Network. If the access point is in the Black Network it has to be physically protected and access to the console port may need to be limited (e.g., tamper tape), or the port deactivated. Some vendors may produce both solutions. If

WPA3 terminates on APs rather than on the WLAN Controller, then the connection between the APs and the WLAN Controller must be encrypted in a manner leveraging IPsec, SSHv2, TLS, DTLS, or TLS/HTTPS.

If WPA3 terminates on the WLAN Controller, then the WPA3 encryption is used to protect the connection between the APs and the WLAN Controller.

The WLAN Access System must be capable of initiating and terminating multiple cryptographic tunnels to and from numerous Wireless Clients. It must also be capable of translating EAP-TLS over 802.1X messages to EAP-TLS over Remote Authentication Dial in User Service (RADIUS) messages to pass authentication information between the WLAN Client and WLAN Authentication Server. This exchange mailto:csfc@nsa.gov involves a Pairwise-Master Key (PMK) that is negotiated between the WLAN Client and the WLAN

Authentication Server. The WLAN Authentication Server passes the PMK to the WLAN Access System over an IPsec tunnel, DTLS or TLS/RADsec tunnel. The Wireless Controller and the WLAN Client use the

PMK to negotiate a session key to protect the subsequent user traffic exchanged between the WLAN

Client and the WLAN Access System. As mentioned above, the WLAN Access System should operate on its own separate hardware and/or virtual device(s), depending on the vendor implementation. This separation may include isolating the switches and wiring between the APs and the controller from any existing network. At the very least, the WLAN Access System and the VPN Gateway must operate on separate hardware. Since the WLAN Access System is deployed between the Black Network and the

Gray Network, it is essential to implement port filtering on the WLAN Access System’s Gray Network interface to prevent unauthorized traffic. Traffic should be restricted using configuration requirements stated in Section 12.7.

5.2 GRAY FIREWALL

The Gray Firewall is located between the…