802.1X and EAP

EAP = Extensible Authentication Protocol which is a universal layer 2 based authentication protocol use on point-to-point, wired, and wireless networks. EAP is used by 802.1X for port based, network access authentication. There are many EAP types however the most commonly used are EAP-PEAP, and EAP-TTLS.

1) EAP-TLS is well supported and use by wireless vendors although a challenge to implement as it requires both a client-side and server-side certificate. General comment is that EAP-TLS is the best security option but also the most difficult to implement.

2) EAP-TTLS was co-developed by Funk and Certicom. It differs from EAP-TLS in that the server only needs to be authenticated to the client by certificate (signed by public or private CA). 802.1X supplicants need to properly verify the certificate otherwise potential for man in the middle interception exists (when used with wireless). Microsoft does not natively support EAP-TTLS.

3) EAP-PEAP is a joint effort of Cisco, Microsoft, and RSA and is widely in use. Similar to EAP-TTLS, MS-CHAPv2 login credentials are protected by TLS during the authentication process. Bottom line is that if you are dealing with the Microsoft 802.1X supplicant (which most of us probably would be), then PEAP is your friend.

There seems to be very little in the way of documentation on the net with regard to how 802.1X port authentication and EAP-PEAP actually function. It is an interesting protocol dance when you have Protected Extensible Authentication Protocol (PEAP) involving layer 2 traffic from the 802.1X supplicant, protected by TLS within the EAP over LAN (EAPOL) transactions, and also with the TLS data carried within the Radius attribute value pairs.

The server side certificate presented via Radius back to the client may be a public CA signed, or internal/privately signed certificate. In either case, it is critical that the 802.1X supplicant (client station) has a properly imported root certificate.

With regard to the EAPOL (EAP over LAN) transactions, a lot of documentation I have read fails to recognize that an EAP-Request/Identity frame is always initiated from the switch first with link up. I only mention this point as it came to light in recent EAPOL debugging/diagnostic work I was involved in.

And BTW, if you are ever looking at 802.1X/PEAP/Radius authentication traffic, a useful 'tcpdump' filter is as follows:

'ether proto 0x888e OR udp port 1812'

This assumes that Radius traffic is being carried on UDP port 1812 and that you are able to mirror/span the data from your AP/switch (authenticator) as well as your client/supplicant.

The EAP transactions occur at OSI layer 2 between the supplicant and the authenticator while the synchronized Radius transactions occur at OSI layer 3 between the AP/switch authenticator and the Radius server. The TLS certificate and data is carried both within the EAP traffic, and within the Radius attribute-value pairs between client/supplicant and Radius server.

Thus, your network management network better be functioning reliably!




So having written all that, I wonder if we can use the EAP-Response/Identify frame to send an extremely large string or perhaps even 'printf' based format string to exploit weaknesses in the authenticator or Radius code. At minimum, a potential denial of service could exist if not worse condition.

Covert Channel Possibilities!

The IT network and security community often thinks of covert channels in terms of what has already been detected. A good example is Loki, and other ICMP variants. However, we should not forget that IP, TCP, UDP, and ICMP headers and payloads contain opportunities to hide data in storage channels.

Header and application payload fields that can potentially be used for covert storage channels include the IP Identification field (16-bits), the TCP Initial Sequence Number (32-bits), the DNS identification field (16-bits), the TCP timestamp option (32-bits x 2), a portion (or all) of the source IP address, a TCP or UDP source port (16-bits) just to name a few.

Some of these fields are deliberately (and highly) randomized during certain normal protocol transactions. Thus, if we combine storage of covert data with symmetric key encryption, and nicely crafted bogus payload, we can yield a highly effective and hard to detect channel.

When doing protocol and intrusion analysis, we should be careful to look at packet timing, and uni-directional versus bi-directional nature of protocol transactions. You never know when you might be witnessing a covert storage or timing channel at work, and you might never really discover the content.