Closest I can do to layman's terms, slightly oversimplified, and limited to just WPA2 for simplicity's sake:
802.1X is NOT an encryption type. It is basically just a per-user (e.g. username and password) authentication mechanism.
WPA2 is a security scheme that specifies two main aspects of your wireless security:
- Authentication: Your choice of PSK ("Personal") or 802.1X ("Enterprise").
- Encryption: Always AES-CCMP.
If you're using WPA2 security on your network, you have two authentication choices: You either have to use a single password for the whole network that everyone knows (this is called a Pre-Shared Key or PSK), or you use 802.1X to force each user to use his own unique login credentials (e.g. username and password).
Regardless of which authentication type you've set up your network to use, WPA2 always uses a scheme called AES-CCMP to encrypt your data over the air for the sake of confidentiality, and to thwart various other kinds of attacks.
802.1X is "EAP over LANs" or EAPoL. EAP stands for "Extensible Authentication Protocol", which means it's kind of a plug-in scheme for various authentication methods. Some examples:
- Do you want to authenticate your users with usernames and passwords? Then "PEAP" is a good EAP type to use.
- Do you want to authenticate your users via certificates? Then "EAP-TLS" is a good EAP type to use.
- Are the devices on your network all GSM smartphones with SIM cards? Then you can use "EAP-SIM" to do GSM SIM-card style authentication to get on your network. etc. etc.
If you set up your wireless router to use 802.1X, it needs to have a way to authenticate your users via some EAP type. Some routers may have the ability for you to input a list of usernames and passwords right on the router, and the router knows how to do the whole authentication all by itself. But most will probably require you configure RADIUS. RADIUS is a protocol that allows you to keep your username and password database on a central server, so you don't have to make changes on each separate wireless router each time you add or delete a user or a user changes his password or something. Wireless routers that do 802.1X generally don't know how to authenticate users directly, they just know how to gateway between 802.1X and RADIUS so that the wireless client machines are actually getting authenticated by a RADIUS server on the network, and it's the RADIUS server that knows how to deal with various EAP types.
If your wireless router's user interface has "802.1X" on a list of encryption types, then it probably means "802.1X with dynamic WEP", which is an old scheme where 802.1X is used for authentication, and per-user per-session WEP keys are dynamically generated as part of the authentication process, and thus WEP is ultimately the encryption method used.
Update re: two logical ports
To answer your question about two logical port entities, there are two separate concepts in the 802.1X spec that you may be referring to.
First, the 802.1X spec defines client and server roles for the 802.1X protocol, but it calls them the Supplicant and Authenticator, respectively. Within your wireless client or your wireless router you have software that performs the role of the 802.1X Supplicant or Authenticator. This software that performs that role is called a Port Access Entity or PAE by the spec.
Second, the spec mentions that within, say, your wireless client machine, there must be a way for your 802.1X Supplicant software to access your wireless interface in order to send and receive EAP packets to accomplish authentication, even when no other networking software on your system is allowed to use the wireless interface yet (because the network interface isn't trusted until it's been authenticated). So the in the weird engineering legalese of IEEE spec documents, it says there's a logical "uncontrolled port" that the 802.1X client software hooks up to, and a "controlled port" that the rest of the network stack hooks up to. When you first attempt connection to an 802.1X network, only the uncontrolled port is enabled while the 802.1X client does its thing. Once the connection has been authenticated (and, say, WPA2 AES-CCMP encryption has been set up to protect the rest of your network transmissions), then the controlled port is enabled so that the rest of the system sees that network link as "up".
Long Answer, not so much in layman's terms:
IEEE 802.1X is a way to do per-user or per-device authentication for wired or wireless Ethernet LANs (and potentially other network schemes in the IEEE 802 family). It was originally designed and deployed for wired Ethernet networks, and was later adopted by the IEEE 802.11 (wireless LAN) working group, as part of the 802.11i security addendum to 802.11, to serve as a per-user or per-device authentication method for 802.11 networks.
When you use 802.1X authentication on your WPA or WPA2 network, you're still using WPA or WPA2's confidentiality ciphers and message integrity algorithms. That is, in the case of WPA, you're still using TKIP as your confidentiality cipher and MIChael as your message integrity check. In the case of WPA2, you're using AES-CCMP which is both a confidentiality cipher as well as a message integrity check.
The difference when you're using 802.1X is that you're not using a network-wide Pre-Shared Key (PSK) anymore. Because you're not using a single PSK for all devices, each device's traffic is more secure. With PSK, if you know the PSK and capture the key handshake when a device joins the network, you can decrypt all of that device's traffic. But with 802.1X, the authentication process securely generates keying material that is used to create a unique Pairwise Master Key (PMK) for the connection, so there's no way for one user to decrypt another user's traffic.
802.1X is based on EAP, the Extensible Authentication Protocol that was originally developed for PPP, and is still used extensively in VPN solutions that use PPP inside the encrypted tunnel (LT2P-over-IPSec, PPTP, etc.). In fact, 802.1X is generally referred to as "EAP over LANs" or "EAPoL".
EAP provides a generic mechanism for transporting authentication messages (authentication requests, challenges, responses, success notifications, etc.) without the EAP layer having to know the details of the particular authentication method being used. There are a number of different "EAP types" (authentication mechanisms designed to plug into EAP) for doing authentication via username-and-password, certificates, token cards, and more.
Because of EAP's history with PPP and VPN, it has always been easily gatewayed to RADIUS. Because of that, it's typical (but not technically required) for 802.11 APs that support 802.1X to contain a RADIUS client. Thus APs typically don't know anyone's username or password or even how to process various EAP authentication types, they just know how to take in a generic EAP message from 802.1X, and transform it into a RADIUS message and forward it to the RADIUS server. So the AP is just a conduit for the authentication, and not a party to it. The real endpoints of the authentication are typically the wireless client and the RADIUS server (or some upstream authentication server that the RADIUS server gateways to).
More history than you wanted to know:
When 802.11 was first created, the only authentication method it supported was a form of shared-key authentication using 40- or 104-bit WEP keys, and WEP was sorta limited to 4 keys per network. All users or devices connecting to your network had to know one of the 4 short keys for the network in order to get on. There was no way in the standard to authenticate each user or device separately. Also, the way the shared-key authentication was done allowed for easy "offline oracle" fast brute-force key-guessing attacks.
Many vendors of enterprise-class 802.11 gear realized that per-user (i.e. username-and-password, or user certificate) or per-device (machine certificate) authentication was necessary to make 802.11 a success in the enterprise market. Even though 802.1X wasn't quite done yet, Cisco took a draft version of 802.1X, limited it to one EAP type (a form of EAP-MSCHAPv2), made it generate per-device per-session dynamic WEP keys, and created what they called "Lightweight EAP" or LEAP. Other vendors did similar things, but with clunkier names like "802.1X with dynamic WEP".
The Wi-Fi Alliance (née the Wireless Ethernet Compatibility Alliance, or "WECA") saw the deservedly bad rep WEP was getting and saw the security scheme fragmentation happening in the industry, but couldn't wait for the IEEE 802.11 working group to finish adopting 802.1X into 802.11i, so the Wi-Fi Alliance created Wi-Fi Protected Access (WPA) to define an interoperable cross-vendor standard for fixing the flaws in WEP as a confidentiality cipher (creating TKIP to replace it), the flaws in WEP-based shared key authentication (creating WPA-PSK to replace it), and to provide a way to use 802.1X for per-user or per-device authentication.
Then the IEEE 802.11i task group finished their work, choosing AES-CCMP as the confidentiality cipher of the future, and adopting 802.1X, with certain restrictions to keep it secure on wireless networks, for per-user and per-device authentication for 802.11 wireless LANs. In turn, the Wi-Fi Alliance created WPA2 to certify interoperability between 802.11i implementations. (The Wi-Fi Alliance is really an interop certification and marketing organization, and often prefers to let the IEEE be the real WLAN standards body. But if the IEEE is too hide-bound and not moving fast enough for the industry, the Wi-Fi Alliance will step in and do standards-body-like work ahead of the IEEE, and usually then defers to the related IEEE standard once it comes out later.)
Actually, the application which determines this information is
aircrack-ng. From the
airodump-ng documentation, power levels are determined as:
PWR - Signal level reported by the card. Its signification depends on the
Well, let's see if we can do better. Looking through the latest source code of the
airodump-ng.c file, we see the power gets set in the
/* only update power if packets comes from
* the AP: either type == mgmt and SA != BSSID,
* or FromDS == 1 and ToDS == 0 */
ap_cur->power_lvl[ap_cur->power_index] = ri->ri_power;
After digging through several layers of abstraction, structs, and function pointers, I found that this data is filled from the function
linux_read(...) defined in the
osdep/linux.c file. This is where the
ri_power variable in the
ri struct is filled with data, and indeed it does appear to be driver specific.
Most drivers follow the Radiotap standard (as opposed to the older prism54 standard detailed below), which have several predefined fields for determining antenna power, noise, and attenuation. These fields are used directly by
airodump-ng to fill in the
ri_power variable. Some of these are already available in decibel or power values.
airodump-ng will use either the antenna signal field (in dBm) or the dB antenna signal field (in dB) to compute the displayed signal power. Similar steps are used for the other fields, as they are all predetermined in the Radiotap specification linked to above. For example, the
ri_power using the dB Antenna Signal field can be computed as:
if( *iterator.this_arg < 127 )
ri->ri_power = *iterator.this_arg;
ri->ri_power = *iterator.this_arg - 255;
got_signal = 1;
As mentioned earlier, some devices follow the (older) prism54 specification (instead of Radiotap), which uses a fixed-length header. In this case, the RX power directly from the buffer (note this is not complete source code, just shows the paths taken to fill
if (tmpbuf == 0x40)
ri->ri_power = tmpbuf[0x33];
ri->ri_power = *(unsigned int *)( tmpbuf + 0x5C );
The 802.1x allows for mutual authentication using PKI in some configurations. This can use TLS, which is the protocol used for secure web browsing.
Both the client and AP have a private/public key-pair. The public keys are included in a certificate that is cryptographically signed by a third system that is configured to be trusted on both the client and AP. As long as the private keys and the and the CA is not compromised both machines can use the protocol to mutually authenticate each other.
The downside is that managing all the PKI takes a lot more effort then a simple shared key.