draining the world\’s beer supply one pint at a time

I’m getting quite irritated by the complete lack of useful information on securing wired networks via 802.1X.   I think it’s worth sharing some of the issues and solutions or work-arounds for a multi-vendor environment, which I’ll do over a series of posts.

Plenty of security vendors will describe how to setup their solutions in a single-vendor environment, but that doesn’t match the real world.  I’ll start by listing out some components from a multi-platform environment.  Subsequent posts will describe issues with each of the various components and key configuration points.

Client environment: Windows XP, Mac OS/X (10.4 and 10.5), Linux (Ubuntu LTS).

IP phones: Avaya 96xx, Cisco 79xx

Switches: Cisco 6500, 3750 and 3650

Firewalls: Juniper SSG (relevant for future NAC deployments)

RADIUS: Microsoft IAS, Infoblox, Juniper Infranet Controller (for future NAC deployments)

Issues:  more machines than network drops at desks, authentication should be transparent to users, re-imaging machines, printers/scanners/etc, “stale” CRL from “root” CAs.

August 20th 2007. Cisco releases IOS 12.2(33)SXH for 6500s with sup32s and 720s. This release actually does useful stuff for 802.1X – almost feature parity with the low-end switches that have had these features “forever”.
Guest VLAN, Auth-fail VLAN, multi-domain, etc etc. FINALLY!

Still playing with the built in OS/X supplicant (make sure the keychain with your 802.1X certificate doe NOT lock on screensaver activation!) whilst I wait for Xsupplicant 1.3 to stabilize.

Got Xsupplicant 1.2.8 working with TLS for the Linux desktops we have here… shame they ripped out the OS/X support in that train only to have to add it back for 1.3

Lets say that you don’t really want users to login, just have a valid certificate.  All your Windows boxes do auto-enrollment and get certificates.  This works transparently.
Macs however…  well, lets just say it took a while to realise that the certificate common name should be the UPN, not the username and not the email address.  Now it works just fine   Needless to say, this was a problem with the certificate server’s templates, not with the mac itself.

Why can’t Cisco? 3560, small stackable switch:

interface GigabitEthernet0/11
 switchport access vlan 803
 switchport mode access
 switchport voice vlan 801
 load-interval 30
 dot1x port-control auto
 dot1x timeout tx-period 10
 dot1x timeout reauth-period 60
 dot1x guest-vlan 1
 dot1x reauthentication
 spanning-tree portfast
end

6500 wiring closet switch:

switch(config)#int faste 1/22 
switch(config-if)#dot1x port-control auto 
Command rejected: One or more ports configured with voice vlan.
Dot1x can't be enabled on voice vlan configured ports.

So how is one supposed to enable 802.1X and use Cisco’s phones?  Double up on switchports and wall jacks.

Cisco claims IOS support on the 6500 for 802.1X and voice VLANs is coming early 2007.  CatOS is supposed to support it, but that’s a backwards step I’m not sure we want to take…

On my campaign for multi-layer network security, we finally enabled 802.1X authentication for wired users in one of our remote offices as a pilot.
(Isn’t it funny how something you mention as an aside can get turned into a full blown project with “can we get this done by the next security meeting?”…)
We have a mix of company issued Windows “productivity” machines, developer Linux and Windows boxes and then the personal laptops (like my powerbook). Everything we do to protect the productivity network has to be Mac compatible because “we” are finally going to support (and provide) Macs!
So, Windows XP 802.1X authentication. By default it’s already configured to try authenticating with a client certificate. This is almost perfect… just one registry setting to be pushed out to tell the stack to use system certificates and authenticate as a machine account, and that meets the goal for the pilot.
Using Microsoft Internet Authentication Service on the domain controllers – very, very, very simple configuration… so simple that this router jockey documented the config.
The client cert comes from the Windows domain… it’s “non-exportable” (whatever that means).
Now the real work begins – trying to get similar functionality on the Mac platform. (Similar functionality here means as little user interaction as possible Yes, the Mac supports 802.1X, but it’s not on by default and is pretty well hidden and needs configuration to work. The client certs don’t appear automatically (why would they? The Macs don’t typically log in to the Windows domain), and so far I haven’t found such a thing as a machine certificate thats non-exportable.
I fully expect that we’ll get the Macs working just as we find the money and time to stop using the built in supplicants and use something that will let us do some security posture analysis (probably Funk’s Juniper’s Odyssey Access Client).