Satellite Provider Petitions FCC for Additional 2.4 GHz Wi-Fi Channel and Exclusive Use

Globalstar, a U.S. company that operates low-Earth orbit (LEO) satellites providing voice and low-speed data communications, petitioned the FCC for approval for terrestrial use of their assigned Big LEO spectrum. Globalstar seeks to develop, market, sell, and deploy an terrestrial FDD LTE service by combing their Lower (1610-1618.725 MHz, uplink transmissions) and Upper (2483.5-2495 MHz, downlink transmissions) Big LEO spectrum. However, coexistence hurdles make terrestrial FDD LTE a long-term goal.

In the short-term, a Terrestrial Low Power Service (TLPS) in the Upper Big LEO spectrum is requested. And the promise is more efficient spectrum usage. Part of their spectrum holdings are directly adjacent to the 2.4 GHz ISM (Industrial, Scientific, and Medical) band in which Wi-Fi operates (they were granted this spectrum in 1995). The TLPS service would effectively enable use of Wi-Fi channel 14 in the U.S., which would increase aggregate Wi-Fi capacity since this channel does not overlap with existing Wi-Fi channels.

However, before you get too excited, realize that the use of this additional Wi-Fi channel would be exclusive to Globalstar.

Terrestrial Low-Power Service.  While the Commission and interested parties work through any technical issues described above, the Commission has an extraordinary opportunity to leverage Globalstar’s spectrum location in the 2.4 GHz band, the public’s prior investment in devices, and existing IEEE 802.11 technology to advance the rapid deployment of an innovative, pro-consumer TLPS.  Applying a unique, hybrid spectrum approach, Globalstar will provide this low-power broadband service over 22 megahertz of spectrum that includes both Globalstar’s exclusive terrestrial use spectrum at 2483.5-2495 MHz and adjacent unlicensed industrial, scientific and medical (“ISM”) spectrum at 2473-2483.5 MHz.  TLPS operations on this 2473-2495 MHz band segment are consistent with the 802.11 channelization scheme

This "hybrid" spectrum approach could have serious implications for spectrum policy in the U.S. The existing ISM band is an unlicensed band, open for use by anyone that meets certification criteria and testing. However, Globalstar effectively wants to retain exclusive use of their licensed spectrum (and rightly so) but couple it with unlicensed ISM spectrum to form this new service offering. The result would be the creation of a "licensed" Wi-Fi channel, that could only be developed and deployed by Globalstar.

The marketing used by Globalstar attempts to spin this approach as increasing the nation's broadband spectrum inventory, increasing capacity in congested metropolitan areas, and providing critical public-safety benefits during natural disasters.

If the Commission implements the necessary regulatory reforms to enable this hybrid approach, it will add 22 megahertz to the nation’s wireless broadband spectrum inventory.  In addition, this spectrum will be put quickly to use as American consumers utilize their current 802.11-enabled devices to receive Globalstar-managed TLPS, which will help alleviate the increasing congestion that is impeding use of existing 802.11 ISM channels in dense metropolitan areas... In addition, TLPS deployments will deliver meaningful public safety benefits.  During disasters such as Hurricane Sandy, still-operating 802.11-based hotspots can provide broadband and voice communications to citizens in affected areas who otherwise lack access to communications services.  The addition of TLPS facilities will augment this important post-disaster resource.

However, I fail to see how this hybrid spectrum policy will accomplish these goals. Since Globalstar will retain exclusive use of their licensed spectrum (2483.5-2495 MHz) no additional spectrum will be added to the nation's broadband spectrum inventory. Despite Globalstar's plans for 20,000 TLPS hotspots, they only currently have 550,000 worldwide subscribers and would likely need to partner with other Wi-Fi hotspot providers such as telecom carriers and wireline broadband providers (such as AT&T, Time Warner, Cablevision, and Comcast). Such business partnerships will prove difficult, as these existing providers will be reluctant to license and pay Globalstar for use of this additional spectrum. Finally, Globalstar's attempts to tie the TLPS service to public-safety are erroneous, since they are coupling the use of Wi-Fi hotspot access with their existing Mobile Satellite Service (MSS). Public safety has benefited from MSS service when terrestrial wireline operator facilities have been knocked out. The key here is the MSS backhaul facility, not the Wi-Fi access on the ground through the TLPS service. Similar public safety services are capable using existing Wi-Fi over unlicensed spectrum.

I'm not a spectrum policy expert. But my opinion is that Globalstar wants everything, but gives little in return. They want hybrid use of unlicensed spectrum coupled with their adjoining licensed spectrum holdings to create an exclusive-use Wi-Fi channel. This goes against the provisions established for the unlicensed spectrum and allows a single entity to profit from use of the spectrum and take advantage of the open nature and existing deployment base of the Wi-Fi eco-system. Moreover, this is simply a short-term plan until a long-term FDD LTE service can be deployed. Ultimately, no additional spectrum will be added for broadband use.

I can only see how this benefits Globalstar, harms unlicensed spectrum policy, and allows Globalstar to take advantage of the benefits of unlicensed spectrum by building an exclusive service on top of the Wi-Fi ecosystem.

I'm against it.

Andrew

Is WPA2 Security Broken Due to Defcon MS-CHAPv2 Cracking?

Quick answer - No. Read on to hear why.

A lot of press has been released this week surrounding the cracking of MS-CHAPv2 authentication protocol at Defcon. For example, see these articles from Ars Technica and CloudCracker. All of these articles contain ambiguous and vague references to this hack affecting Wi-Fi networks running WPA2 security. Some articles even call for an end to the use of WPA2 authentication protocols such as PEAP that leverage MS-CHAPv2.

But they fail to paint a true and accurate picture of the situation and the impact to Wi-Fi networks. I think this is misleading, and that any recommendations to stop using PEAP are flat-out wrong!

So let's clarify things.

Is MS-CHAPv2 authentication broken? 
Answer - Based on what I've read, let's assume it is TOTALLY broken. You can read about the details in those other articles. But for the topic of this post, applicability to Wi-Fi networks, it really doesn't matter if it is broken or not.

What is the Impact to Wi-Fi Network Security?
Specifically, does this make much of an impact for Wi-Fi networks where 802.1X authentication is employed where MS-CHAPv2 is used (namely EAP-PEAPv0 and EAP-TTLS)?
Answer - No, it really does NOT. The impact is essentially zero.

* Update - Microsoft has released a security advisory which recommends the use of PEAP encapsulation to mitigate this attack against un-encapsulated MS-CHAPv2 authentication. 

Let me explain why.

EAP Tunneled Authentication Protocols
MS-CHAPv2 is only used in what we call "tunneled authentication protocols," which includes EAP-PEAPv0 and EAP-TTLS. These EAP protocol specifications acknowledge that many insecure and legacy authentication methods need protection and should not be used on their own. They deal with that by wrapping the insecure protocol inside of another, much more secure, TLS tunnel. Hence, these protocols are called "tunneled authentication protocols."

This tunneling occurs by relying on asymmetric cryptography through the use of X.509 certificates installed on the RADIUS server, which are sent to the client device to begin connection setup. The client verifies the certificate is valid (more on that in a second), and proceeds to establish a TLS tunnel with the server and begin using symmetric key cryptography for data encryption. Once the TLS tunnel is fully formed, the client and server use the less secure protocol such as MS-CHAPv2 to authenticate the client. This exchange is fully encrypted using the symmetric keys established during tunnel setup. The encryption switches from asymmetric key cryptography to symmetric key cryptography to ease processing and performance, which are much faster this way. This is fundamentally the same method used for HTTPS sessions in a web browser.

Here is a reference ladder diagram of PEAP authentication which highlights the different phases of the connection process (outer TLS tunnel setup and inner MS-CHAPv2 authentication).

PEAP Ladder Diagram
(Click for full size image)

So, MS-CHAPv2 is not used natively for Wi-Fi authentication. We're safe right? Only if implemented properly.

Importance of Mutual Authentication
The key link in this chain then is the mutual authentication between the RADIUS server and the wireless client. The client must properly validate the RADIUS server certificate first, prior to sending it's credentials to the server. If the client fails to properly validate the server, then it may establish an MS-CHAPv2 session with a fake RADIUS server and send it's credentials along, which could then be cracked using the exploit that was shown at Defcon. This is commonly referred to as a Man-in-the-Middle attack, because the attacker is inserting their RADIUS server in the middle of a conversation between the client and the user database store (typically a directory server).

RADIUS Server Validation and Exposure to Attack
(Click for full size image)

The RADIUS server is validated as long as the certificate that it sends is trusted. For most client platforms, trusted certificates are provided by the manufacturer for public Certificate Authorities and PKI systems (such as Verisign, Thawte, Entrust, etc.) and are held in the certificate store or keychain on the device. In addition, for corporate environments, administrators can deploy certificates to managed devices in a number of different ways to enable trust for private Certificate Authorities and PKI systems, most common among these methods are Group Policy Objects (GPO) for Microsoft clients and Lion Server Profile Manager or the iPhone Configuration Utility (iPCU) for Apple clients (including OS X and iOS devices).

Enabling Server Certificate Validation on Clients
In Windows the RADIUS server validation is defined within each SSID profile. If you are looking directly on a Windows 7 workstation, you will want to view the SSID properties, select the Security tab, and go into the PEAP settings. Enable server validation, specify valid server names (which are checked against the Common Name - CN within the server certificate presented to the client), restrict which Root CAs the server certificate can be issued from, and prevent the system from prompting users to accept untrusted certificates (which is important, otherwise they could unknowingly accept a bad certificate and connect to an attacker's RADIUS server).

Windows RADIUS Server Validation

In Apple devices, including OS X Lion, Mountain Lion, and iOS, use the Lion Server Profile Manger or iPCU to define a configuration profile which includes credentials and a Wi-Fi policy. I'll show the iPCU in this example. First, add the Root CA certificate into the "Credentials" section. Next, define a Wi-Fi policy which specifies the trusted certificates and certificate names allowed.

Apple RADIUS Server Validation

Client Behavior for Server Validation
In both vendor implementations, the behavior of the client device is dictated by what policy has been defined on the system.

If no policy for the SSID has been defined or pushed to the client device by an administrator, the default behavior is to prompt the user to validate the certificate. This is likely not ideal, since users typically have a hard time distinguishing what a certificate means and whether or not they should proceed. For example, when an Apple iPhone attempts to join a network when no profile has been deployed for that SSID, the user receives a prompt to accept the connection and proceed:

iPhone Certificate Prompt

Therefore, for all corporate 802.1X environments, it is recommended to push profiles for all 802.1X SSIDs that end-users need on their systems. This goes for both production access and BYOD scenarios. The behavior on Windows 7, OS X Lion / Mountain Lion, and iOS devices when a profile has been installed for a specific SSID, is to check the local certificate store or keychain to validate the RADIUS server certificate. It must also match the Root CAs and server names specified in the deployed profile. In the event that an untrusted certificate is presented, all of these systems will NOT prompt the user and the connection is rejected. For example, here is rejected connection by an Apple iPhone for an SSID that has had a profile deployed by an administrator:

iPhone Certificate Rejection

Outstanding Vulnerabilities
You should still be aware of a few indirectly related vulnerabilities that have not yet been resolved relating to Wi-Fi authentication with 802.1X.

First, the default behavior of all systems (especially personal devices) is to prompt users to validate the RADIUS server certificate. This is often confusing and can lead to bad actions being taken by users and attempted authentication through an attacker's RADIUS server. This can be mitigated by having corporate environments deploy configuration profiles for all SSIDs in their network, both production and BYOD. Don't fall into the trap for BYOD of letting users connect on their own and try to decipher the certificate prompt. Establish a sound personal device on-boarding process which deploys a configuration profile to the device upon successful enrollment and policy acceptance. There are numerous ways to do this, ranging from simple solutions such as sending them a profile in an email or providing a web URL where users can download the profile, to more complex solutions such as MDM integration that allow self-registration and zero IT involvement.

Second, certificate binding to the SSID is still a manual process on wireless networks. It must be defined within the configuration profile. This is in contrast to SSL and TLS protocols that are used for secure web access where the end-user system can automatically verify if the FQDN within the URL matches the Common Name presented in the certificate. The manual binding process in Wi-Fi networks is born out of a lack of extensibility within the PKI system to handle network access scenarios such as this. A better solution is needed.

Finally, certificate revocation checking cannot occur by Wi-Fi clients since they do not yet have a network connection with which they can query a CRL distribution point or use OCSP. This means that client devices cannot check the status of the presented server certificate to see if it has been revoked, which could be caused by valid certificates that have subsequently been compromised or certificates that were invalidly issued by a CA. However, there is hope that the forthcoming 802.11u extensions to Wi-Fi can provide the means for this to occur through message exchanges prior to full network connection (thanks to Christopher Byrd for pointing this out to me during a Twitter conversation).

Revolution or Evolution? - Andrew's Take
We've known that MS-CHAPv2 is an insecure protocol for a long time. The recent Defcon exploit has just taken that one step further. Development of modern Wi-Fi security recognized the possible value in using legacy protocols such as these. Therefore, EAP protocols that employed such protocols were designed to tunnel the insecure protocol within a much more robust protocol such as TLS. These "tunneled authentication protocols" such as PEAP ensure protection for these insecure protocols through the use of certificates.

The onus for proper security then falls on RADIUS server validation to ensure the other end of the connection is trusted before allowing the client authentication to proceed. In a properly implemented wireless network, this MS-CHAPv2 exploit is a non-issue.

There is no need for Wi-Fi network administrators to abandon PEAP. Period.

Security is a complex field. It may be hard to distinguish the FUD from fact. If you're interested in learning more about Wi-Fi security, then I highly recommend engineers take training provided in the CWSP (Certified Wireless Security Professional) course offered by CWNP, Inc. or the SEC-617 (Wireless Ethical Hacking, Penetration Testing, and Defenses) course offered by the SANS Institute.

Cheers,
Andrew vonNagy

"Hotspot Zones" Born from Muni-Fi Failures and Hotspot Successes

Remember all those failed Muni-Fi (or Metro Wi-Fi) deployments in the mid-2000's? Well, most of them failed due to a combination of poor business planning where no anchor tenancy was established, advertising wasn't sufficient to foot the bill, over-zealous Wi-Fi design that called for far too few wireless APs (and subsequently poor performance), and difficulty in obtaining access rights to utility poles to get power and backhaul for AP locations which stalled deployments. (Read about all that over here; Minneapolis seems to be one bright spot in all that).

Now, Muni-Fi appears to be making a bit of a comeback. Although everyone has ditched that terminology, likely to avoid bringing the negative connotation that now comes with it :) This is not completely without just cause, as the focus has shifted from providing pervasive coverage over entire cities, to focused coverage in specific public areas where it makes sense. In some respects, I consider these new deployments a hybrid between Muni-Fi (pervasive public area coverage) and Hotspots (coverage in a specific location, typically tied to an establishment such as a coffee shop). I'd call them "Hotspot Zones".

AT&T and other carriers have installed hotspot zones in a few major urban areas, such as Manhattan and San Francisco. And Wi-Fi is even being installed in old phone booths in NYC to ease rights-of-way issues.


LightReading describes this initiative:

New York City's plan to house hot spots in pay phones to provide free Wi-Fi service in the Big Apple illustrates just how much wireless LAN has become part of everyday life even as the public telephone system has become a thing of the past. 

The city is working with pay-phone companies Titan and Van Wagner to install the hot spots, according to NY1 TV.

And the folks at Smart Wi-Fi provide insight on the economics of deployment in old phone booths:

Obviously phone booths are connected via the two wires needed for a POTS line which could easily be augmented with a DSL session.  Along with power, the locations can easily be re-born to a ‘smartphone’ world.  Maybe we can dub these “smartphone booths”. 

Putting Wi-Fi access points into un-used phone banks makes some sense, particularly with the new Next Generation Hotspot (NGH) and HotSpot2.0 initiatives.  Acompany can use their right-of-way to install and maintain the access points while changing back-end service providers (Boingo, iPass, AT&T, …) to enable their subscriber’s access.

What's the difference this time around?

First, and most importantly, the deployment model has shifted from "large-scale" Wi-Fi installations trying to light up entire cities and communities, to much more focused "hotspot-zones" where Wi-Fi is deployed in areas that make sense from a public and consumer point-of-view.

Second, Wi-Fi is much more accessible and mobile than it was 7-10 years ago. Users increasingly no longer need to carry around laptops to access Wi-Fi hotspots, they have much more convenient access from smartphones and tablets. That should help increase adoption, improve the free Wi-Fi through advertising business model, and help these hotspot zones succeed.

Finally, Wi-Fi technology has dramatically improved with 802.11n, offering better speeds and rate-over-range for customer devices, translating into better service quality and perception.

It's all about the business model folks :) Okay - and some technology too.

Cheers,
Andrew