CAPT Jon Kennedy OSD (NII) Communications Directorate

1. DoDD 8100.2 and Follow-on Policy Security Boundary End-to-end, Security Border, and Assured Channel Explained26 April 2007 CAPT Jon Kennedy OSD (NII) Communications Directorate

2. WLAN Architecture: Policy Requirements for Encryption Internet ISP Router Autonomous AP Architecture Firewall User E2.1.1. Assured Channel. A network communication link that is protected by a security protocol providing authentication, confidentiality& data integrity, and employs U.S. Government-approved cryptographic technologies whenever cryptographic means are utilized… Access Point Laptop WG Switch Core Switch Public or insecure network segment that must be protected DoD Network Certificate Authority RADIUS Assured Channel FIPS 140-2 Validated Encryption Security Border ISP Router Public or insecure network segment that must be protected Firewall DoD Network AP Controller or WLAN Switch User Internet WG Switch Access Point Core Switch Laptop Certificate Authority WLAN Switch/Controller Architecture RADIUS

3. WLAN Architecture: Policy Requirements for Encryption Internet ISP Router Autonomous AP Architecture Firewall User E2.1.7. End-to-End. Is from the end-user device up to the security border of a DoD network and/or between two user devices connected by a DoD/non-DoD network (to include the wireless infrastructures air interface). Access Point Laptop WG Switch Core Switch end-to-end Certificate Authority RADIUS Non-DoD Network DoD Network Security Border Internet ISP Router DoD Network Non-DoD Network Firewall end-to-end User AP Controller or WLAN Switch Access Point Laptop WG Switch Core Switch Certificate Authority WLAN Switch/Controller Architecture RADIUS

4. WLAN Architecture: Policy Requirements for Encryption • Question: Can OSD provide more detail and/or a specific example of “assured channel”? Is it intended that authentication and encryption must coincide as endpoints of an assured channel? (source: DoDD 8100.2, 4.1.2, E2.1.1) • Answer: Assured channels represent a communication stream that is protected by a technology (or cryptographic module) that implements FIPS 140-2 validated encryption. Assurance is in the confidentiality of the data that, as it passes over unprotected or insecure segments of the network, it will remain confidential until it safely arrives on a network owned and operated by the DoD that is protected and secure.

5. WLAN Architecture: Policy Requirements for Encryption • Question: Can OSD provide more detail and/or a specific example of “end-to-end” and the intent for “security border”? (source: DoDD 8100.2, 4.1.2, E2.1.7) • Answer: End-to-end: Is from the end-user device up to the security border of a DoD network and/or between two user devices connected by a DoD/non-DoD network. This means that the first end of the end-to-end communications is the end-user device, and the other end is the first point over which the data will be traveling that represents a DoD owned and operated network. If for example, a user was in a public hotspot, then the end-to-end concept being described would span from the [end-user --> the hotspot LAN --> Internet -->DoD gateways --> users home enclave external firewall]. On the other hand if it were a WLAN located on a DoD base, where an end-user was connecting to the base through a WLAN AP, then the end-to-end concept would only span the following [end-user --> air interface --> AP]; since the AP is directly connected to a DoD owned and operated network, thereby representing the end with the 802.11i encryption protecting the insecure section (i.e. the wireless air interface).

6. WLAN Architecture: Policy Requirements for Encryption • Question: What is the scope of “wireless devices” in the directive – specifically, does this apply only to devices that have an RF interface (ie, “points without physical connection)? (source: DoDD 8100.2, 4.1.2, E2.1.22) • Answer: In the DoDD 8100.2 the scope of the wireless devices being addressed, covers a multitude of wireless devices, except for a few select categories of devices (i.e. receive-only pagers, GPS receivers, implanted medical devices, RFID, bar code scanners, etc.). The DoDD 8100.2 was intended to be an overarching wireless policy that sets the high-level requirements for all wireless devices. After its ratification follow-on policies were (and continue to be) developed to provide further clarification on the specifics of particular wireless device categories.

7. WLAN Architecture: Policy Requirements for Encryption • Question: Assume the intent is for multiple vendors to provide solutions and choices; as such, does the definition of “Open” here inherently imply specific architectural guidance in terms of encryption points? In other words, can encryption occur at different locations based on different vendor implementations as long as overall end-to-end security requirements are met? (source: DoD WLAN Policy Memo - Use of commercial WLAN..., June 6, 2006, Bottom of first page, "Open Architectures" & “Open Standards.”) • Answer: Yes, as long as the end-to-end requirements are met, vendor implementation can vary. End-to-end requirements are to protect all data-in-transit as it travels over vulnerable segments of the network (i.e. segments of the network not owned and operated by the DoD, or wireless portions of the network that a susceptible to eavesdropping).

8. WLAN Architecture: Policy Requirements for Encryption • Question: Does this mean DAA responsibility is to enforce one common OSD definition of “end-to-end” or do they individual discretion in the definition and implementation of the policy? (source: DoD WLAN Policy Memo - Use of commercial WLAN..., June 6, 2006, Section 1.b(d), components shall ensure that the system meets overall end-to-end security requirements as approved by the DAA.) • Answer: DAAs reserve the right to deviate from the policy, but rarely do. DoD policies drive security requirements. Policies such as DoDD 8100.2 set requirements at the overarching level, yet there are times where specific mission requirements are weighed against individual risks within the operating environment. The DAA can individually deviate from specific requirements. Ultimately, for a system to be acquired and then granted the authority to be operated by a DoD Component, the DAA has to review a security assessment package that allows them to make an informed decision about the risks of operating a particular system. The DAA uses policy requirements such as those listed in the DoDD 8100.2 policy to make these risk based decisions. The DAA process of acceptance of a systems risk is called “certification and accreditation”, which is defined in the DoD’s DIACAP process.

9. WLAN Architecture: Policy Requirements for Encryption • Question: Does the policy mandate that both functions (authentication and encryption) be performed on the same physical device? For example, as long as the designated protocols requirements are met, can encryption occur on the AP, and authentication occur on the WLC?(source: DoD WLAN Policy Memo - Use of commercial WLAN..., June 6, 2006, Section 1.c(1), WLAN Authentication and Encryption) • Answer: Yes, these two functions can be handled separately. Authentication and encryption requirements, and their being processed by the same device, is not specified and therefore is not a requirement. There is a requirement for 802.11i WPA2 compliant/certified EAP-TLS authentication, which will likely use a RADIUS server in order to be in compliance with 802.11i and Wi-Fi Alliance requirements. The purpose is to ensure that IEEE standards, industry best practices are adhered too, and that the solution will undergo Federal government security validations (FIPS 140-2 CMVP and NIAP Common Criteria).

10. Point of Contact • Department of DefenseOffice of the Assistant Secretary of DefenseCommunications DirectorateCAPT Jon Kennedyjon.kennedy@osd.mil(703) 607-0736