Wednesday, 17 April 2013

Extensible Authentication Protocol - EAP

To validate users at Layer 2, a protocol called Extensible Authentication Protocol (EAP) is used within the IEEE 802.1x framework.

EAP operation, consists of three distinctive elements:

      Supplicant ------ Authenticator ------ Authentication Server

In WLANs a supplicant is a software running on a STA, authenticator is either an Access Point or Wireless Controller. The authentication server is usually a RADIUS server.

The authenticator maintains two virtual ports, an uncontrolled port and a controlled port. The uncontrolled port allows EAP authentication traffic to pass through, and the controlled port blocks all other traffic until the supplicant has been authenticated.

With EAP authentication protocols both server-side and client-side certificates can be used.

EAP messages are encapsulated in EAP over LAN (EAPOL) frames.

IEEE 802.1x/EAP authentication framework utilizes IEEE 802.11 Open System authentication. An STA will initially join a BSS (authenticate and associate at Layer 2) and will only proceed to Layer 3 (i.e DHCP request) if the entire IEEE 802.1x/EAP process is successful.

Generic EAP process flow:

1. Authenticator sends an EAP Request to a Supplicant when it connects to the network.

2. The Supplicant sends an EAP Response to the Authenticator, which embeds the EAP packet into a RADIUS request and sends it to Authentication Server.

3. The Authentication Server negotiates the EAP method for authentication. The Supplicant can acknowledge the EAP method that the EAP server suggests or, it can respond with a negative acknowledgement (NAK) and suggest a list of alternative EAP methods. The Authentication Server and the Supplicant must reach agreement about the EAP method to use to proceed with authentication.

Weak EAP Protocols:

   EAP-MD5:
   - One-way authentication only
   - Username sent in clear text
   - Weak MD5 Hash

   EAP-LEAP:
   - Pseudo-mutual authentication
   - Username sent in clear text
   - Weak MS-CHAPv2 Hash
   - Cisco proprietary

Strong EAP Protocols:

   EAP-PEAP:
   - EAP-PEAPv0 (EAP-MS-CHAPv2)
   - EAP-PEAPv0 (EAP-TLS)
   - EAP-PEAPv1 (EAP-GTC)

   EAP-TTLS

   EAP-TLS (most secure, highly recommended for use in enterprise WLAN)

   EAP-FAST (Cisco proprietary, uses PACs - Protected Access Credentials) 



References:

User Guide for the Cisco Secure Access Control System 5.2
CWSP Certified Wireless Security Professional Official Study Guide

AAA

AAA stands for Authentication, Authorization and Accounting. It's a security architecture which provides control over what services/resources a user can access, how much of the resources a user can access and also provides a trail of the resources used.

Authentication - verifies user identity and credentials (username/password or digital certificate).

In simple words, authentication requires to provide who the user is. there a three ways for a user to present credentials:

- Something a user know
- Something a user have
- Something a user is  

Multifactor authentication describes a situation where multiple credentials are presented, i.e. something you know (username/password) and something you have (smart card)

Authorization - grants access to network resources and services.

Proper authentication must occur, before authorization to network resources can be granted.

Accounting - tracks the use of network resources by users.

 
It is strongly advisable to use IEEE 802.1x authentication framework in enterprise WLANs. IEEE 802.1x is a port-based access control standard that defines the mechanism necessary to authenticate and authorize devices to network resources.

Very often RADIUS protocol is used with IEEE 802.1x authentication framework. RADIUS stands for Remote Authentication Dial-In User Service. and is a protocol that uses the following ports:

1812/udp (or legacy 1645/udp) - authentication
1813/udp (or legacy 1646/udp) - accounting

Aggressive Load Balancing on Cisco WLC

Wouldn't it be nice to be able to balance client distribution on the wireless network from a controller?
Cisco WLC provides us with a feature called "Aggressive Load Balancing", it works at the association phase  . When a STA attempts to associate to a LAP, association response packets are sent to the STA with an 802.11 response frame including status code 17. This code indicates whether the LAP can accept any more associations (in other words the AP is saying "I'm busy, go away"). If the AP is too busy, the STA attempts to associate to a different access point in the area.

And here's a problem, it is the responsibility of the STA to honor, process or discard the association response frame with reason code 17.  Some clients ignore it, even though it is part of the 802.11 specification. The standard dictates that the STA driver must look for another AP to connect to because it receives a "busy" message from the first AP it tries. Many STAs don't do this and send the association request again. The client in question is allowed on to the wireless network upon subsequent attempts to associate.

Anyway, the way to configure aggressive load balancing on WLC is following:

1. Globally configure aggressive load balancing:


Client Window Size - value between 1 and 20. The algorithm that determines whether an AP is too heavily loaded to accept more client associations:

load-balancing window + client associations on AP with lightest load = load-balancing threshold

In the group of APs seen by a STA, each AP has a different number of client associations. The AP with the lowest number of clients has the lightest load. The client window size plus the number of clients on the access point with the lightest load forms the threshold. APs with more client associations than this threshold is considered busy, and STAs can associate only to APs with client counts lower than the threshold.

Example: A STA can see 3 APs, AP1, AP2 and AP3:

AP1 = 5 associated clients
AP2 = 7 associated clients
AP3 = 12 associated clients

Client Window Size = 5

Load-balancing threshold = 5 + 5 = 10

AP3 is considered to be busy, because the client count on it (12) is higher that the threshold (10).

Maximum Denial Count - value between 0 and 10. The denial count sets the maximum number of association denials during load balancing.

Example: continuing the previous example, if a STA ignores the code 17 in association response sent by AP, and keeps sending association requests to AP3, when the STA sends association request for the fourth time, AP3 will allow the STA to associate.

2. Load balancing is configured per WLAN:




It is only possible to load balance clients between access points on the same controller. Load balancing doesn't work between access points on different controllers.

References:

Cisco wlc 7.0 configuration guide
Cisco support forum

Tuesday, 16 April 2013

Wi-Fi Subtleties Explained (Throughput Algebra) - CWNP blog

Links to WiSE articles on Wi-Fi throughput algebra:

First article: http://www.cwnp.com/cwnp_wifi_blog/the-wise-article-series-wi-fi-subtleties-explained-throughput-algebra/

UDP throughput is roughly 2/3 of data rate
TCP throughput is roughly 1/2 of data rate

Second article: http://www.cwnp.com/cwnp_wifi_blog/the-wise-article-series-wi-fi-subtleties-explained-parameters-that-matter/

30% improvement in the throughput with the use of 40 MHz channels compared to 20 MHz channels

Third article: http://www.cwnp.com/cwnp_wifi_blog/the-wise-article-series-wi-fi-subtleties-explained-channel-bonding/

Cisco WLC Broadcast and Muticast

Broadcast and multicast traffic often require special treatment within a WLAN network because of the additional load placed on WLAN. In order for all STAs associated to an AP to receive broadcast and multicast traffic, it needs to be sent at the lowest common bitrate.

The default behavior of the WLC is to block broadcast and multicast traffic from being sent out the WLAN to other STAs. The WLC can do this without impacting client operation because most IP clients do not send broadcast/multicast traffic for any reason other than to obtain network information (DHCP) and resolve IP addresses to MAC addresses (ARP).

DHCP

The WLC acts as a DHCP relay agent for associated WLAN clients. It unicasts client DHCP requests to locally configured or upstream DHCP server except during L3 client roaming. DHCP server IP address(es) are configured for each dynamic interface, which is associated with one or more WLANs. DHCP relay requests are forwarded via the dynamic interfaces using the source IP address of a given dynamic interface. Because the WLC knows which DHCP server to use for a given interface/WLAN, there is no need to broadcast client DHCP requests out its wired and wireless interfaces.

ARP

Before a WLAN client can send IP packets to any other IP address, it needs to know the MAC address of the target client to forward the frame to. To accomplish this a client will broadcast an ARP query, equesting the MAC address for the IP host that it wishes to communicate with.

When a WLC sees a wireless client ARP request, it will either respond directly, acting as an ARP proxy in behalf of the wireless client, or it will forward the request out it's wired interface to have it resolved by another WLC. The WLC will not forward the ARP broadcast back out to the WLAN.

Multicast can be explicitly enabled on a WLC, but this requires some steps to be taken to minimize the multicast traffic generated on those interfaces that the WLC connects to. When multicast is enabled, it is a global setting, which means it will be enabled for every WLAN configured regardless if multicast is needed by the WLAN or not.



References:

Cisco Enterprise Mobility 4.1 Design Guide

Implementing an OCSP responder

I recently asked a friend of mine, who is a security engineer that is currently doing a "deep dive" into PKI, about CRL (Certificate Revocation List) concept. He explained it to me, plus dag a little bit deeper, extending it to OCSP (Online Certificate Status Protocol). I'm sharing it here.


For example, let’s say you issue a User certificate to a user for authentication. When the user leaves the company you will most likely want to make sure no one can use that certificate for authentication so you log onto the Certificate Authority and revoke that certificate. Each CA has a period specified when it publishes what are called Certificate Revocation Lists or CRLs for short. When the next CRL is published it will contain the serial number of the certificate, the date and time it was revoked, and the reason that the certificate was revoked. Depending on the configuration the CA it will publish the CRL to a repository such as an LDAP server or a web server. In some instances a task or job must be created to copy the CRL to a repository.
Aside from CRLs, there are also delta CRLs. Delta CRLs simply contain the revocation information for certificates that have been revoked since the last Base CRL was published. In order to determine revocation status an application would examine the last base CRL, and the latest delta CRL. The reason for publishing delta CRLs is to provide revocation information that has more current data. Also, it can reduce bandwidth since if the base CRL is already cached on the client, just the delta CRL can be downloaded. More on this later.
In order for applications to determine if a certificate has been revoked, the application examines the CRL Distribution Point (CDP) extension in the certificate. This extension will have information on locations where the CRL can be obtained. These locations are normally either HTTP or LDAP locations.
The application then can go to those locations to download the CRL. There are, however, some potential issues with this scenario. CRLs over time can get rather large depending on the number of certificates issued and revoked. If CRLs grow to a large size, and many clients have to download CRLs, this can have a negative impact on network performance. More importantly, by default Windows clients will timeout after 15 seconds while trying to download a CRL. Additionally, CRLs have information about every currently valid certificate that has been revoked, which is an excessive amount of data given the fact that an application may only need the revocation status for a few certificates. So, aside from downloading the CRL, the application or the OS has to parse the CRL and find a match for the serial number of the certificate that has been revoked.
With the above limitations, which mostly revolve around scalability, it is clear that there are some drawbacks to using CRLs. Hence, the introduction of Online Certificate Status Protocol (OCSP). OCSP reduces the overhead associated with CRLs. There are server/client components to OCSP: The OCSP responder, which is the server component, and the OCSP Client. The OCSP Responder accepts status requests from OCSP Clients. When the OCSP Responder receives the request from the client it then needs to determine the status of the certificate using the serial number presented by the client. First the OCSP Responder determines if it has any cached responses for the same request. If it does, it can then send that response to the client. If there is no cached response, the OCSP Responder then checks to see if it has the CRL issued by the CA cached locally on the OCSP. If it does, it can check the revocation status locally, and send a response to the client stating whether the certificate is valid or revoked. The response is signed by the OCSP Signing Certificate that is selected during installation. If the OCSP does not have the CRL cached locally, the OCSP Responder can retrieve the CRL from the CDP locations listed in the certificate. The OCSP Responder then can parse the CRL to determine the revocation status, and send the appropriate response to the client.

Here's the source on the Microsoft technet:


Thanks Karol.

Monday, 15 April 2013

Capturing 802.11 frames with Wireshark and Airmon-ng

One of an easy way to capture wireless frames is to use Wireshark. We will use linux (Ubuntu in my case, but any other distro is fine) and an Aircrack-ng suite to achieve our goal.

If you need some help on how to install Aircrack-ng, the best place to find the info is on Aircrack-ng website: http://www.aircrack-ng.org/

First let's find out if the OS detected our wireless NIC:

root@ubuntu:~# iwconfig
wlan1     IEEE 802.11bg  ESSID:off/any 
               Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm  
               Retry  long limit:7   RTS thr:off   Fragment thr:off
               Encryption key:off
               Power Management:off

As we can see the "wlan1" is detected by the OS.

We will use only airmon-ng program, which is part of the Aircrack-ng suite, to put the interface in monitor mode, but first we will "shutdown" the wireless interface:

root@ubuntu:~# ifconfig wlan1 down

This will allow us to set the interface to a specific channel (if we don't do that the interface driver will be hopping through all channels), but first we will verify the driver is correctly installed:

root@ubuntu:~# airmon-ng

Interface    Chipset        Driver


wlan1        RTL8187     rtl8187 - [phy2]


Now we can put the wireless card in a monitor mode, and at the same time we'll set it to operate on channel 6 (802.11b/g):

root@ubuntu:~# airmon-ng start wlan1 6

....

Interface    Chipset        Driver

wlan1        RTL8187     rtl8187 - [phy2]
                (monitor mode enabled on mon0)

New interface has been created: "mon0", this can also be verified with:

root@ubuntu:~# iwconfig
mon0      IEEE 802.11bg  Mode:Monitor  Frequency:2.437 GHz  Tx-Power=20 dBm  
               Retry  long limit:7   RTS thr:off   Fragment thr:off
               Power Management:on
         
wlan1     IEEE 802.11bg  ESSID:off/any 
               Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm  
               Retry  long limit:7   RTS thr:off   Fragment thr:off
               Encryption key:off
               Power Management:off

We can see that mon0 interface is in "Monitor" mode and is set to frequency 2.437 GHz (channel 6), this can be further verified with a "iwlist" command:

root@ubuntu:~# iwlist mon0 frequency
mon0      14 channels in total; available frequencies :
               Channel 01 : 2.412 GHz
               Channel 02 : 2.417 GHz
               Channel 03 : 2.422 GHz
               Channel 04 : 2.427 GHz
               Channel 05 : 2.432 GHz
               Channel 06 : 2.437 GHz
               Channel 07 : 2.442 GHz
               Channel 08 : 2.447 GHz
               Channel 09 : 2.452 GHz
               Channel 10 : 2.457 GHz
               Channel 11 : 2.462 GHz
               Channel 12 : 2.467 GHz
               Channel 13 : 2.472 GHz
               Channel 14 : 2.484 GHz
               Current Frequency:2.437 GHz (Channel 6)

Now all we need to do is to start Wireshark, and capture 802.11 frames (on mon0 interface), also make sure you ticked the box "Capture all in promiscuous mode" under "Options".

When you've finished capturing, after closing Wireshark, you can take out the interface from monitor mode, with:

 root@ubuntu:~# airmon-ng stop mon0


Interface    Chipset        Driver

mon0        RTL8187     rtl8187 - [phy2] (removed)
wlan1        RTL8187     rtl8187 - [phy2]


Happy wireless sniffing!