Friday 16 May 2014

Understanding Wireless Authentication and Encryption

A strong understanding of authentication and encryption is essential to deploy a secure and functional WLAN. Evaluate the different options against the goals of the organization and the security and operational requirements that the organization operates under. The number of different authentication and encryption options that must be supported also influences the design of the WLAN and the number of SSIDs that must be broadcast.
In general, each new authentication type or encryption mode that is required means that an additional SSID must be deployed. To preserve radio resources, organizations should consider the types of devices to be deployed and attempt to limit the number of SSIDs. Remember that each SSID that is deployed appears as an individual AP, and it must beacon, which uses up valuable airtime.
Wi-Fi networks have multiple authentication methods available for use. Each method depends on the network goals, security requirements, user types, and client types that will access the network. Consider the types of data that will flow over the network, as that will narrow the authentication and encryption choices.
Layer 2 authentication occurs before the client can complete a connection to the network and pass traffic. As the name suggests, the client does not have an IP address at this stage.
Open authentication really means no authentication. The network is available for anyone to join and no keys are required. This form of authentication is often combined with a Layer 3 authentication method that is used after connection to the network.
Wired equivalent privacy (WEP) is the original security mechanism that was built into the 802.11 standard, and several variations are available. The most common version is static WEP where all stations share a single key for authentication and encryption. Other versions of WEP have different key lengths and dynamic key assignments.
As an authentication and encryption protocol, WEP was fully compromised in 2001. Automated tools make it easy to access a WEP network with no expertise or training. WEP is considered no more secure than an open network. Most recommends that all organizations discontinue the use of WEP and replace any older WEP only devices with more capable systems as soon as is practical.
MAC authentication is an early form of filtering. MAC authentication requires that the MAC address of a machine must match a manually defined list of addresses. This form of authentication does not scale past a handful of devices, because it is difficult to maintain the list of MAC addresses. Additionally, it is easy to change the MAC address of a station to match one on the accepted list. This spoofing is trivial to perform with built-in driver tools, and it should not be relied upon to provide security.
MAC authentication can be used alone, but typically it is combined with other forms of authentication, such as WEP authentication. Because MAC addresses are easily observed during transmission and easily changed on the client, this form of authentication should be considered nothing more than a minor hurdle that will not deter the determined intruder. Most recommends against the use of MAC-based authentication.
Pre-shared key (PSK) authentication is the most common form of authentication for consumer Wi-Fi routers. Like WEP, the key is used both for both authentication and encryption. In enterprise deployments, PSK is often limited to devices that cannot perform stronger authentication. All devices share the same network key, which must be kept secret. This form of authentication is easy to configure for a small number of devices. However, when more than a few devices must use the key, key management quickly becomes difficult.
The key usually must be changed manually on devices, which poses more problems if the number of devices that share a key is very large. When an attacker knows the key, they can connect to the network and to decrypt user traffic. Good security practice mandates that the key should be changed whenever someone with access to the key leaves the organization.
In some guest deployments, PSK is used to provide a minimum amount of protection for guest sessions, and authentication is performed by a Layer 3 mechanism. This key should also be rotated on a regular basis.
802.1X was developed to secure wired ports by placing the port in a “blocking” state until authentication is completed using the Extensible Authentication Protocol (EAP). The EAP framework allows many different authentication types to be used, the most common being Protected EAP (PEAP), followed by EAP-TLS that uses server- and client-side certificates.
To secure user credentials, a Transport Layer Security (TLS) tunnel is created and user credentials are passed to the authentication server within the tunnel. When the authentication is complete, the client and the Mobility Controller (tunnel mode) or AP (decrypt tunnel and bridge modes) has copies of the keys that are used to protect the user session. The 802.1X handshake is seen in below Figure .
The  Mobility Controller forwards the request to the RADIUS server that performs the actual authentication and sends a response to the Aruba controller. When authentication completes successfully, the RADIUS server passes encryption keys to the  Mobility Controller. Any vendor-specific attributes (VSAs) are also passed, which contain information about the user. A security context is created, and for encrypted links, key exchange occurs where all traffic can now be encrypted.
Mobility Controller uniquely supports the AAA FastConnect feature, which allows the encrypted portions of 802.1X authentication exchanges to be terminated on the Mobility controller. The hardware encryption engine dramatically increases scalability and performance. AAA FastConnect is supported for PEAP-MSCHAPv2, PEAP- GTC, and EAP-TLS. When AAA FastConnect is used, external authentication servers do not need to handle the cryptographic components of the authentication process. AAA FastConnect permits several hundred authentication requests per second to be processed, which increases authentication server scalability. The complete authentication process is seen in Figure .
If the user already exists in the active user database and now attempts to associate to a new AP, the mobility controller understands that an active user has moved, and it restores the user connectivity state. 
Machine authentication authenticates Windows-based machines that are part of an Active Directory domain. Before the user logs in, the machine authenticates to the network and proves that it is a part of the domain. After that authentication succeeds or fails, the user can log in using 802.1X. Based on the combinations of success or failure, different roles on the system are assigned. Table describes the possible condition states.
Table  Machine Authentication Pass or Fail Matrix
Machine Auth Status
Machine authentication and user authentication fails. Layer 2 authentication fails.
Machine authentication fails (for example, the machine information is not present on the server). User authentication succeeds. Server-derived roles do not apply.
authentication is configured in the 802.1X authentication profile.
Machine authentication succeeds and user authentication has not been initiated. Server-derived roles do not apply.
Machine authentication default machine role is configured in the 802.1X authentication profile.
The machine and user are successfully authenticated. If server-derived roles have been defined, the role assigned via the derivation take precedence. This case is the only one where server-derived roles are applied.
A role that is derived from the authentication server takes precedence. Otherwise, the 802.1X authentication default role that is configured in the AAA profile is assigned.
For clients that do not support Wi-Fi Protected Access® (WPA™), VPN, or other security software, Aruba supports a web-based captive portal that provides secure browser-based authentication and third-party captive portals. Captive portal authentication is encrypted using Secure Sockets Layer (SSL) to protect credentials. Captive portal authentication supports:
Captive portal uses the Aruba integrated internal database and guest provisioning system to provide a secure guest access solution. Captive portal permits front-desk staff to issue and track temporary authentication credentials for individual visitors (see Figure ).
Typically a guest user connects to the guest SSID, which requires no 802.11 (Layer 2) authentication and provides no encryption, and is placed in a state that requires login. When the user opens a web browser, a captive portal screen asks them to enter credentials, enter an email address, or simply accept a set of service terms. The captive portal page can be customized with a different background, content, and terms of service. Authentication with the mobility controller is protected in an SSL/TLS tunnel. After the captive portal authentication completes, user traffic passes through the controller and without 802.11 (Layer 2) encryption, which leaves transmissions open to interception. Clients should be encouraged to use their own encryption, such as VPN, when using open network connections.
When WEP was compromised, many organizations did not want to give up the convenience of wireless networks, but they needed something with stronger security until the 802.11i amendment was finalized and available. Many organizations resorted to using existing VPN infrastructure to secure the WLAN. This approach provided the security personnel with the sense that they were using a well-known and trusted form of security. The traditional VPN u-turn is seen in Figure .
Figure  VPN over Wi-Fi
The downside is that the VPN infrastructure was not designed for LAN network speeds. The VPN infrastructure was designed to be used across relatively slow WAN connections. End users who expect wire-like speed from the 802.11n network will not be satisfied with VPN over Wi-Fi. Additionally, VPN concentrators had expensive per-seat licenses that were expected to be shared across multiple users who connected for short periods, not extended-use sessions of workers who connected on the campus. The VPN solution is more expensive for the organization because more licenses and VPN concentrators must be acquired.
Table  summarizes the  recommendations for authentication methods.
Recommended only for securing guest access or for devices that do not support stronger authentication. Recommend captive portal after PSK authentication where possible. Change the key often.
The network administrator must not only authenticate devices, but must also select a form of encryption (if any) that will be applied on the physical connection between the user device and the AP. Encryption is strongly recommended in most cases, because the wireless transmissions of an organization are easily captured or “sniffed” directly in the air during transmission.
As the name implies, open networks have no encryption and offer no protection from wireless packet captures. Most hot spot or guest networks are open networks, because the end user is expected to use their own protection methods to secure their transmissions, such as VPN or SSL.
Though WEP is an authentication method, it is also an encryption algorithm where all users typically share the same key. As mentioned previously, WEP is easily broken with automated tools, and should be considered no more secure than an open network. Aruba recommends against deploying WEP encryption. Organizations that use WEP are strongly encouraged to move to Advanced Encryption Standard (AES) encryption.
The Temporal Key Integrity Protocol (TKIP) was a stopgap measure to secure wireless networks that previously used WEP encryption and whose 802.11 adapters were not capable of supporting AES encryption. TKIP uses the same encryption algorithm as WEP, but TKIP is much more secure and has an additional message integrity check (MIC). Recently some cracks have begun to appear in the TKIP encryption methods. Aruba recommends that all users migrate from TKIP to AES as soon as possible.
The Advanced Encryption Standard (AES) encryption algorithm is now widely supported and is the recommended encryption type for all wireless networks that contain any confidential data. AES in Wi-Fi leverages 802.1X or PSKs to generate per station keys for all devices. AES provides a high level of security, similar to what is used by IP Security (IPsec) clients. Aruba recommends that all devices be upgraded or replaced so that they are capable of AES encryption.
In most instances, a new encryption type requires an additional SSID to support that new encryption mode. Mixed mode allows APs to combine TKIP and AES encryption on the same SSID. The encryption type is selected based on what the client station supports, and the strongest encryption possible is used for each client.
Table  summarizes the recommendations for encryption on Wi-Fi networks. As a reminder, full 802.11n rates are only available when using either open (no encryption) or AES encrypted networks. This is a standards requirement for 802.11n.
The Wi-Fi Alliance is a trade group that is made up of 802.11 hardware vendors. The Wi-Fi Alliance created the Wi-Fi Protected Access (WPA) and WPA2™ certifications to describe the 802.11i standard. The standard was written to replace WEP, which was found to have numerous security flaws.
It was taking longer than expected to complete the standard, so WPA was created based on a draft of 802.11i, which allowed people to move forward quickly to create more secure WLANs. WPA2 encompasses the full implementation of the 802.11i standard. Table summarizes the differences between the two certifications. Remember that WPA2 is a superset that encompasses the full WPA feature set.
Temporal Key Integrity Protocol (TKIP) with message integrity check (MIC)
Advanced Encryption Standard – Counter Mode withCipher Block Chaining Message Authentication Code (AES-CCMP)
Table summarizes the recommendations for authentication and encryption combinations that should be used in Wi-Fi networks.
AES if possible, TKIP or WEP if necessary(combine with restricted PEF user role).

No comments:

Post a Comment