Aamir Lakhani wrote a fantastic post on 802.1x for DOD. You can find the original posting at www.cloudcentrics.com
The Department of Defense added a requirement that all network ports, or on-ramps need to be protected. Applications, server, and data are normally protected; however, most network ports are left open. You get on to a network by plugging into a port and a network address is allocated for the connection. Computers without proper are free to launch attacks from the network. Network port protection lock down restricts anonymous access and prevents these “attacks”.
When network protection is turned on, a machine plugs into the network; no network access is given until the machine is authenticated to the network.
A few years ago, NAC solutions tried to accomplish goals for locking down networks. Most of my customers hated NAC. It added a layer of complexity that made the network behave unnatural and harder to support. It used a variety of ports, protocols, and physical boxes to implement. In short, it was complicated. NAC supported networks broke down often, causing nightmares for those legitimate users trying to get access and the people supporting those networks.
What are people doing to support port lockdown today at the Department of Defense and other large enterprise organizations? Surprisingly, the solution has been around for a long time to help secure wireless networks. It is called 802.1x. Historically, 802.1x has worked great on wireless networks and has always been a little troublesome on the wired ports. But things have changed with enterprise policy servers (Cisco Identity Services) that make the connection more easily configurable on modern day operating systems such as Mac OS X Mountain Lion and Windows 8.
How does 802.1x work? According to Wikipedia, IEEE 802.1X is an IEEE Standard for port-based Network Access Control (PNAC) that provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. It is part of the IEEE 802.1 group of networking protocols.
802.1X authentication involves three parties: a supplicant, an authenticator, and an authentication server. The supplicant is a client device (such as a laptop) that wishes to attach to the LAN/WLAN. The term ‘supplicant’ is also used interchangeably to refer to the software running on the clients’ device that provides credentials to the authenticator. The authenticator is a network device, such as an Ethernet switch or wireless access point. And the authentication server is typically a host running software supporting the RADIUS and EAP protocols.
The authenticator acts like a security guard to a protected network. The supplicant (i.e., client device) is not allowed access through the authenticator to the protected side of the network until the supplicant’s identity has been validated and authorized. A similar comparison to this would be providing a valid visa at the airport’s arrival immigration booth before being allowed to enter the country. With 802.1X port-based authentication, the supplicant provides credentials, such as user name / password or digital certificate, to the authenticator and the authenticator forwards the credentials to the authentication server for verification. If the authentication server determines that the credentials are valid, the supplicant (client device) is allowed to access resources located on the protected side of the network.
DISA (Defense Information Systems Agency) and the DOD (Department of Defense) have mandated that all government network on-ramp ports will be configured and protected by 802.1x technologies through a STIG.
A Security Technical Implementation Guide or STIG is a methodology for standardized secure installation and maintenance of computer software and hardware. This term was coined by DISA, which creates configuration documents in support of the United States Department of Defense (DOD). The implementation guidelines include recommended administrative processes and span of the devices’ lifecycle.
An example where STIGs would be of benefit is in the configuration of a desktop computer. Most operating systems are not inherently secure leaving them open to criminals such as identity thieves and computer hackers. A STIG describes how to minimize network-based attacks and prevent system access when the attacker is present at the device. STIG also describes maintenance processes (such as software updates and vulnerability patching).
Defense agencies do not have a choice. They must comply with STIG or go through lengthy time-consuming process of getting exceptions. Some customers will buy older hardware, that is more expensive and out dated simply because it complies with STIG or some other regulation. Vendors have to submit their products to the government to get STIG approved. This process has high costs associated for the vendor. The process also takes a long time to complete, sometimes over a year. By the time a product is certified, in many cases it is outdated.
Most organizations will get audited on how they comply with STIG. Therefore, organizations try and read the STIG and comply with it the best they can. The biggest problem is sometimes; the STIG can be open to interpretation. Although, a STIG is revised often, it can become outdated since updates cannot keep with the revisions of the technology. This leaves organizations in an interesting situation. Should they go with the best solution, following the intent of the STIG or go with the exact prescription of STIG and stick as close to the language and products as possible.
Most auditors I spoke to prefer the latter. They believe no matter how good an organization’s intentions are, they simply do not have the resources to test new solution products. They rather prefer solution products that are already tested and certified.
An advanced STIG (version 8, release 10) states, “The IAO will ensure that 802.1x is implemented using a secure EAP such as EAP-TLS, EAP-TTLS or PEAP” under Group ID V-7542.
Additionally, Group ID: 5626 states, “the switch must be configured to use 802.1 x authentications on host facing access switch ports”. Lastly, Group ID: 5624 states, “the IAO/NSO will ensure if 802.1x Port Authentication is implemented, re-authentication must occur every 60 minutes.”
It is recommended that defense agencies and organizations will have to implement 802.1x technologies. They can buy products such as Cisco’s Identity Services Engine (Cisco ISE) to accomplish this task. However, the organization must still engineer and design the implementation of the solution. The biggest hurdle facing most establishments is what EAP type should be implemented when deploying 802.1x. The STIG states, “the IAO will ensure that 802.1x is implemented using a secure EAP such as EAP-TLS, EAP-TTLS or PEAP.”
Arguably, EAP-TLS is the most secure protocol because both the client and the server validate each other before access granted. The biggest hurdle is that it requires a certificate authority server (CA) that both the authenticator server and the client trust. In many cases, DOD CA root servers are controlled from a central authority. Individual agencies do not manage certificate servers and must work with other groups to attain valid certificates. This can be a painful and time-consuming task.
In addition, EAP-TLS requires client machines to have certificates installed. In many cases this means some sort of configuration on every client machine that connects to the network. Although, there are tools that help automate this process, they are not easy. The task is even more daunting when you consider endpoints may be scattered throughout the world.
EAP-FAST is another option. It has most of the benefits of EAP-TLS without the requirement of having certificates. The concern with EAP-FAST is that it is a Cisco proprietary protocol. Many people prefer open standard protocols, yet, the STIGs do not prohibit EAP-FAST or a proprietary protocol; they just prohibit insecure protocols. EAP-FAST requires the Cisco AnyConnect software on each client machine and distributing software is much easier than distributing and configuring certificates. Cisco’s AnyConnect is available on Windows, Mac OS X, Apple, iOS, and Google Android platforms.
The most popular EAP implementation I ran into is EAP-PEAP. PEAP unlike EAP-TLS, requires only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server.
PEAP then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server’s public key. The exchange of authentication information inside the tunnel to authenticate the client is then encrypted and user credentials are safe from being stolen.
PEAP appears to be a secure protocol and is stated as an acceptable protocol in the STIG. However, it may not be as secure as we think.The STIG clearly reads, “The IAO will ensure that 802.1x is implemented using a secure EAP such as EAP-TLS, EAP-TTLS or PEAP.”
STIG protocols are just examples, the guideline calls for secure EAP, PEAP is not considered secure anymore. As of August 2012, MSCHAPv2 has been broken and rendered vulnerable.
Security and privacy researcher Moxie Marlinspike released the tool ChapCrack after his demonstration at the 2012 Defcon Conference that renders MS-CHAP v2 to a computational intensive mathematical key that can be easily broken. It should also be noted that MS-CHAP v2 is widely used in enterprise wireless networks that use WPA2.
So how should organizations following DISAs STIG implement 802.1x and be in compliance? There are options. EAP-FAST seems to be an extremely attractive option. An organization can mitigate the risks of MS-CHAPv2 while gaining the advanced EAP-FAST extensions such as EAP Chaining (currently only available on Windows platforms). It does require the Cisco AnyConnect agent. I feel the agent is much more stable and provides a consistent and better user experience than the native OS client.
I am also a fan of EAP-TLS. It is a proven method that works. However, DOD organizations will need to plan ahead, obtain certificates, and design a proper implementation strategy.
I have had a lot of success implementing 802.1x technologies. We often want to rush things; choose lowest quoting contractors with the fastest timelines. To implement 802.1x right, it takes time and experience. A little bit of hassle upfront for planning and implementation will result in a more secure network.
7 thoughts on “802.1X Challenges For Department of Defense”
I absolutely agree with this article. EAP-TLS today is a proven authentication method that works, and is secure, however, requires much more design and implementation effort. That said, EAP-FAST v2 offers significant advantages, and I would expect this to be more broadly adopted in the industry moving forward.
Also, the added benefit of certificate based authentication includes the idea of determining asset ownership, and potentially using other attributes of the certificate to make some determination of asset type. All good things when it comes to determining security policy for the user and/or device accessing the network.
Good information and I agree with it. I have a Cisco WLC 2504 and 2 x air-lap1142n-n-k9 aps in my home network. All laptops, pc, tablets , ipods can access the wlan once I’ve configured them to discover networks, configure the SSID and PSK WPA2 phase. My one and only Windows 8 machine cannot connect, the WLC debuging states the Win 8 machine is trying to authenticate using 802.1x even though I configured PSK WPA2 with AES
Any idea’s how to get Windows 8 to stop using 802.1x?
I’ll ask my engineering group however with windows 7 / XP, 802.1x is not enabled by default. Customers have to push out a change to all machines to enable that function. MACs on the other hand are cool and already have 802.1x enabled. My guess is windows 8 has 802.1x enabled. You could disable it. I’ll ask and get back to you shortly. Sorry I’m a MAC guy and don’t have a windows 8 system to test with yet but plan to update a testing laptop soon.
The ultimate solution will be realized when the standard DoD desktop supports eap chaining. Every person that accesses a DoD network has a CAC, in that CAC is a certificate. When logging into a standard DoD desktop the cert in the CAC plus the password are used for user authentication. So why not just use the same methodology to do the machine auth? That is the best solution however to do that today you need anyconnect to support the eap chaining. Hopefully in windows 9 eap-chaining will be supported and then comply to connect nirvana might be reached.
We are running into a problem managing 802.1x implementation using certificate base secure authentication while still complying with other STIGs, specifically V ID 4444 that requires “System cryptography: Force strong key protection for user keys stored in the computer.”
Few problems we ran into. First, certificate auto-enrollment does not work with this setting enabled. This can be dealt with by manually issuing a server certificate to the Network Policy Server, but a password has to be entered for the private key. When 802.1x authentication is attempted afterwards with this setting enabled, it fails because the server is attempting to access the private key without using a password.
We have not been able to find a way around this unless we, (1) issue the certificate with the setting disabled on the NPS server so that a certificate without a private key password can be generated, at which point the setting can be re-enabled but appears to not break anything. Or (2), create a cert with a private key password but not enable the cryptography setting on the NPS server so that it doesn’t have to provide password when accessing the private key.
How are we supposed to reconcile the two requirements?
Glad to see people are still accessing some of the older posts on here. I’ll run this by some ISE project managers and get their thoughts. I should have something shortly.
I think this discussion is good and certainly agree that all user-facing access ports should have some form of port security turned on to keep unauthorized devices from connecting. However, on devices isolated in a properly secured Network/Server room without user-facing port access that is another story.
The STIG form 2015 seems to agree – (NOTICE THE NOT below and location exception)
“Verify if the switch configuration has 802.1x authentication implemented for all access switch ports connecting to LAN outlets (i.e. RJ-45 wall plates) or devices not located in the telecom room, wiring closets, or equipment rooms.”
“If classified LAN drops are not authenticated by an 802.1x implementation, they must be located within spaces properly established as Secret vaults, Secret Secure Rooms (AKA: Collateral Classified Open Storage Areas), TS secure room, or SCIF. Otherwise, one of the following supplemental physical security controls must be implemented.”