Monday, October 20, 2008

Hop-by-Hop Encryption: Needed?

Mike Fratto's article New Protocols Secure Layer 2 caught my attention:

[T]wo protocols -- IEEE 802.1AE-2006, Media Access Control Security, known as MACsec; and an update to 802.1X called 802.1X-REV -- will help secure Layer 2 traffic on the wire... 802.1AE ensures the integrity and privacy of data between peers at Layer 2. The enhancements in 802.1X-REV automate the authentication and key management requirements for 802.1AE.

802.1AE protects data in transit on a hop-by-hop basis... ensuring that the frames are not altered between Layer 2 devices such as switches, routers, and hosts.


I think the diagram explains 802.1AE well, and Mike notes the problems with this approach:

The default encryption algorithm, AES-GCM, will require a hardware upgrade in network infrastructure and host network interface cards...

[A]ny products that transparently process network traffic, like load balancers, traffic shapers, and network analyzers, will be blind to 802.1AE-protected traffic.


That's a significant problem in my opinion. Already I hear from network administrators who complain about IPSec because it renders the same tools and techniques useless.

The diagram shows that a network analyzer attached to a SPAN port avoids the blind spots introduced by 802.1AE. Another approach would be to introduce a 802.1AE-aware network tap. I do not believe anything like that exists yet, but I would like to see vendors offer this feature.

It appears 802.1AE might defeat the old school layer 2 hacking that continues to surface on modern networks. We'll see how it performs in real life.

The encryption mechanics deserve some attention:

802.1AE is only half the story, however, because it deals only with encryption and integrity -- both of which require keys. 802.1X-REV provides key management--creation, distribution, deletion, and renewal of encryption keys...

Many organizations' physical wiring has one physical LAN port per desk or cubicle, and 802.1X on a wired network was originally designed to be deployed on a one-host-per-port basis. However, it's now common for sites to have multiple hosts per port...

802.1X-REV addresses these issues by allowing multiple hosts to authenticate on a port.

But authenticating multiple hosts isn't enough. If a workstation is connected to a VoIP phone and was properly authenticated, someone could simply clone the workstation's MAC address and connect to the network through that VoIP phone. The bogus workstation would have network access until 802.1X required a reauthentication.

Pairing 802.1X-REV with a workstation NIC that supports 802.1AE enables multiple hosts to be authenticated simultaneously, and each host can have its own encrypted session. More important, bogus workstations can't simply plug in, because the impersonators won't have the encryption keys and therefore can't communicate with the switch.


That last point is significant. I have not personally configured port-based security in production, but I do wonder how people using port-based security handle situations like this. A related issue involves virtual machines sharing a NIC, connected to one physical switch port. Is it acceptable to manually configure the right number of MAC addresses for that port?

5 comments:

Sid said...

There a drawback with 802.1X. If you unplug a legitimate host, then replug through a hub, then it will re-authenticate and re-open the port. Then you plug your rogue workstation, spoof the MAC address, and optionally remove the legitimate one. And here you go.

Instead of encryption, I would far prefer authentication and integrity. Why not use all this key material generated during 802.1x handshake to simply produce HMACs ?

Mike Fratto said...

Rich, I spoke with a few analyzer vendors like Fluke, WildPackets, network general about support for 802.1AE. The basic response was "if there is demand, we will look into it." I am no cryptographer, but it seems to be an intractable problem since 802.1X-REV is meant to thwart man in the middle sniffing. In-line Taps, on the otherhand would have to act like switches.

I have spoken with a number of orgs that have deployed 802.1X on their LAN. They way they deal with hosts that don't have a supplicant like printers is to either put them on quarantine VLAN, white list the MAC, or use MAC authentication where the switch port is the supplicant. Yes, they know it's a weakness, but they bite it anyway.

Sid, most switches can be configured to only allow one MAC, so that stops multiple hosts. The scenario you describe is a problem that can't be solved via 802.1X. However, with 802.1X-REV and 802.1ae using encryption or signing, then a forged host has to have both the MAC and the key. So that will stop simple MAC spoofing. But you need an 802.1AE NIC. The benefit of encrypting between the workstation and the switch is, of course, to ensure data privacy. Like we found with IPSec, the performance hit of encryption over authentication is negligible. Conformant 802.1ae peers should only add less than a MS of latency.

Roland Dobbins said...

Overencryption continues to be a serious problem with regards to the ability to classify network traffic; this is a direct result of the 'encryption = security' mismeme which has been promulgated by all and sundry, over the years.

That being said, I believe that 802.11ae-enabled network infrastructure devices should be able to offer flow telemetry and SPAN-/port mirroring-type packet-replication capabilities, given that the encryption is hop-by-hop, rather than end-to-end. This is probably an implementation issue, and folks should contact their vendors in order to express their desire for this type of functionality, if traffic visibility is important to them.

Mike Fratto said...

Roland, that what you will be left with--relying on the switch to generate telemetry data of span frames.

But, I also misspoke and Nick Ilyadis, VP and CTO from Broadcomm corrected me on a point. He said "The [802.1ae] protocol allows for an offset into the packet for encryption to begin. This allows the IP header to be in the clear so that inter-networking devices can do their thing.

So now I know.

JJ (Jennifer Jabbusch) said...

Hi Richard,
I have some info on securing multi device auth with current 802.1X on my blog..

http://securityuncorked.com

http://securityuncorked.com/2008/10/clearing-up-8021x/

-jj