Sean Convery

Last week Burton held the Catalyst conference in San Francisco. Besides some good networking and above-average conference food, there were some interesting talks and a couple thoughts worth posting here. First, I was shocked by the size of the identity management track in terms of the space it occupied. There were four tracks running simultaneously on day one and the identity management track seemed to be bigger in terms of attendance and space than the rest of the tracks combined. Clearly this is a hot space getting a lot of attention.

This leads directly to my second observation though; the entire track made no mention of the network and seemed firmly focused on classic application IDM and single-sign-on initiatives. The network security tracks were similarly devoid of much real detail on identity. This confirms what I’ve been seeing for a while, these two sides just aren’t talking to one another enough. This is somewhat surprising given that the notion of federated identity has a natural role linking the network and the application. While federation today refers to linking the identity systems of multiple organizations, a far easier and equally fruitful endeavor might be to link the network identity event with application identity. Whether using protocols like SAML or something more basic, allowing an application to verify the network identity of a user seems useful.

As network transport gets more secure either through VPNs, WPA, or newer initiatives like the IEEE LinkSec work (802.1ae/af/ar) the network identity event could perhaps be used as a proxy for application authentication in certain environments. Even better would be linking authorization systems using protocols like XACML. Imagine an environment where you can author policies in one location for application and resource access and they are enforced by both the network and the application using differing techniques. Defense-in-depth indeed!

Next up was a great presentation by Bob Blackley titled Identity and Community in Human Society. I hope he posts his slides to the web soon as they are quite interesting. Anyone who quotes T.S. Eliot in a presentation is O.K. by me.

Finally there were a few good mentions of 802.1X. Some of the wireless talks seemed to indicate that though there was an even split between VPN and 802.1X WLAN security solutions, 802.1X was the trend moving forward. The talk delivered by a Sun Microsystems employee on their NAC deployment was interesting principally because it provided further evidence that appliances are getting the early traction in posture validation: Sun deployed Cisco Clean Access instead of Cisco’s 802.1X based NAC architecture. Another mention of the various NAC frameworks (Cisco NAC, NAP, TCG-TNC) suggested waiting until a more baked standard emerges before deploying. As I’ve said in this blog before, there are plenty of things that most enterprises need to do to prepare for NAC–starting with just basic user authentication at the network and a consistent means of communicating with their directory infrastructure.

For a marketing guy, Josh Lucas at Extreme seems to really get it in a recent TechWorld article. Though he quotes the bogus statistic of “80% of attacks coming from the inside” his thoughts on the virtualization of security services and the role of 802.1X as “one of the first ideas of how to distribute enforcement through the network” are spot on. I wish Extreme had a bit more of a footprint in enterprise networks today so that their ideas would hold more weight in the standards bodies and in pushing the incumbents to work faster.

When discussing 802.1X, authenticated networks, and RADIUS with customers I’m often confronted with a small bit on confusion with regard to the deployment options. The standard way of thinking about 802.1X is that it represents an all or nothing proposition. You either configure and install supplicants on all endpoints (with standard exceptions for printers and the like) or you use an overlay (non-802.1X) authentication technology which typically employs some variation of a captive portal. The captive portal is a device that forces traffic through itself and can force authentication at that step (just like hotel broadband). However, a nice feature on most switches enables smoother 802.1X migration as well as long term interoperability with non-802.1X systems (like guest or contractor machines). This feature is the default VLAN and what it basically says is if the client does not respond to the EAPoL challenge it is placed on a default VLAN. One viable deployment choice has this default VLAN routing traffic through a captive portal where web-based authentication can take the place of the 802.1X authentication step. Some network devices support this web authentication on their hardware directly which represents yet another choice.

Regardless of which technique you choose this gives IT departments the ability to roll-out authenticated networks without managing massive exception lists or maintaining support for 802.1X supplicants on outdated client OSs. It also gives a natural incentive in places like universities to encourage migration. Because the 802.1X route can be considered “fast-path” as it doesn’t involve sending traffic through an unnecessary intermediary device, students can be encouraged to deploy a supplicant to get faster network access.

My company, Identity Engines, just released version 3.0 of our policy decision / AAA platform. You can read the press release here. The major new feature is a user provisioning framework that allows Ignition to send a set of arbitrary VSAs to the enforcement point as a result of the policy decision. These VSAs can be tuned based on the vendor of the enforcement point, the location on the network, or any information we learn about the user from the back end directories. This is the next step in offering some ability to centralize authorization rules within the platform. We’re out at Interop this week showcasing the new functionality. If you are in town, feel free to stop by and say hello.

Joel Snyder at Network World has just posted a great article comparing the major offerings in the NAC space from Cisco, Microsoft, Juniper, and the TCG. If you are new to this space, this is an excellent primer.

I’ve just posted the talk I’m set to deliver 45 minutes from now at the Secure IT Conference. There are two versions available. The first is the basic pdf file of my slides. The second is the notes version with some additional details (but smaller slides). This contains some of the info I talked to rather than presented on screen. Beware, both of these files are over 6MB in size. I’m trying to figure out why, there isn’t anything terribly complicated in the slides. Given the file sizes, if you haven’t seen the talk I recommend starting with the first version. I also linked this talk on my main page.

On Wednesday the 22nd I’m speaking at the SecureIT 2006 conference in Anaheim. The talk’s title is “802.1x: An IT Rorschach Test.” The following is the abstract: “The IEEE 802.1x standard for network authentication has been lambasted and praised, called both a dangerous diversion of an organizations resources and the foundation for the next-generation of user-based network services. But which is it? Early deployments of 802.1x (particularly in wired environments) ran into significant deployment issues which left some organizations soured to the entire notion of a campus authentication event at the network edge. This coupled with the relative stability of alternatives such as IPsec, SSL-based VPNs, and simpler options such as in-line web authentication have stalled installations and even pilots. However, there are organizations who are getting use out of 802.1x today and have managed to successfully roll out the technology in service of their organizations business goals. This talk will explore 802.1x deployment focusing on the lessons learned from both successful and unsuccessful early adopters. The largest challenges such as exception management, supplicant strategies, directory integration, and AAA infrastructure availability will be explored in detail. Additional topics covered include IT organizational issues, integration with other security technologies, and the direction of 802.1x as a technology (including security considerations). Attendees should have a basic understanding of network security including AAA. Prior 802.1x knowledge is not required.” I’m still polishing the slides but will post a PDF of them after the conference.

I hope everyone had a great holiday, I figured a post about toys might be appropriate…

Fresh from CES, Broadcom is announcing a WiFi video phone chipset which includes 802.1x and WPA. It will be interesting to see how the commercial WiFi market embraces 802.1x as well as the home telephony space. Certainly using 802.1x as a mechanism for accessing the network makes sense and by having everything in a single handset you overcome some of the supplicant challenges enterprises are dealing with today. In theory you could also use the 802.1x authentication credentials to differentiate service to users. Federated hotspot roaming can’t be far behind, but the requirements on the back-end AAA infrastructure will be tremendous.

Along this same vein, Kodak announced one of their cameras would support 802.1x a while back. This strikes me as a tad ambitious as I wouldn’t expect any home users to advance beyond WPA personal for some time. That said, Kodak likely didn’t self-develop the supplicant and perhaps it came along for free with the rest of the WPA toolkit. Somehow I wouldn’t expect EAP-TLS anytime soon.

Search Security has an interesting article highlighting some of the challenges of rolling out secure wireless within the University of New Hampshire. The article also highlighted an interesting point on the public safety implications:

“We thought about the students instant-messaging back and forth on where to meet and at what time,” said Green, network manager for the UNH telecom department. “You don’t want the bad guys to intercept those IM transmissions and know where those students are.” They realized wireless security is also an extension of public safety — a way to protect students from predators.

My initial reaction was this seemed alarmist but then I thought about the massive concentration of young students, most of whom embrace IM and its variants. They’ll also be congregating in key areas of campus. The benefit to a predator of sniffing this traffic probably exceeds what they’d glean from your average Starbucks hotspot.

Those of you who’ve been in the IT industry for a long enough time have seen a remarkable evolution in connectivity. The evolution occurred so slowly that perhaps you missed it. Let’s back up to the early 1990s before IP really caught on in the enterprise space. Network engineers—myself included—were running around getting our Certified Netware Engineer (CNE) certifications and spending a lot of time building networks that ran IPX. IPX was a remarkably simple protocol that used a variation of the machine MAC address as the L3 IPX address. If this sounds a bit like IPv6, it should. Both derive the L3 address from the L2 address and make connectivity fairly easy, at least on a local level.

Skip forward to the mid 1990s and we were all enamored with the Internet and the possibilities of TCP/IP. Like me, perhaps you took part in the installation of your company’s first Internet firewall / bastion host. One thing you did, firewall or not, was configure static IP addresses. Lots of them…On every host that used TCP/IP. This is because DHCP didn’t materialize first as RFC 1531 until 1993 (It later became RFC 2131) and didn’t get deployed ubiquitously for a while after that. In that time between IPX and DHCP, configuring these static IP addresses was a pain. The chance of misconfiguration was high, and you tracked all your IP networks in an Excel spreadsheet. You knew that Bob’s IP address was 192.0.2.45 because you hard coded it as such just the other day. If you wanted to write a security policy for Bob, for all practical purposes 192.0.2.45 = Bob.

Static configuration was a particular pain for the network admins themselves who were constantly moving machines around the network for testing and troubleshooting. Since the Excel spreadsheet was invariably a bit out of date and your time on any IP network was limited, you tended to guess an address for the last octet of your machine’s IP address. Sometimes you guessed right, sometimes you guessed wrong and the gratuitous ARP caused your stack to shut down. Troubleshooting network connectivity had to do with making sure DNS was set right, the default gateway was set right, and you weren’t conflicting with another’s IP address. Of course the fact that TCP/IP stacks weren’t built into Windows until 1995 presented other problems that I won’t go into here.

The point of this trip down IT memory-lane is that since the deployment of DHCP we’ve been on a wave of more and more ubiquitous connectivity and less and less troubleshooting per connected station. You move your laptop to another segment, plug in, and get an address that works. IPsec VPNs gave us a small taste of problems as the filtering of ICMP Type 3 Code 4 (Fragmentation Needed and DF bit set) messages by overzealous firewall admins led to MTU issues from the IPsec headers. But for the most part, we’ve experienced a decade or so of fairly consistent connectivity. WLANs just extend the reach of the places you can connect and when combined with home broadband, hotel access, etc. we’ve been in IPv4 connectivity nirvana.

Now you may be wondering whom the villain is in this story and there isn’t one, save progress in general. This time it was progress in security. You see, this ubiquitous connectivity combined with nearly all IP connected stations being Internet connected created a breeding ground for network attacks of all sorts. There’s no need to rehash this except to say the last five years haven’t exactly been in the “Win” column for the good guys.

The latest wave of technology to combat the growth of Internet threats of all kinds is a technology type that I’ll call device posture assessment. Posture assessment products exist or are in development everywhere you look (Cisco, Juniper, Microsoft, TCG TNC, Symantec/Sygate, Consentry, etc.). The basic idea of these systems is to query the state of a connecting machine to see if it is an asset of the organization who runs the network, and if it is up to date with its anti-virus, patch levels, firewall policy, etc. These systems often make use of the RADIUS protocol and slightly less commonly the IEEE 802.1X port authentication standard. While these technologies offer great promise as they mature, they also have the unintended consequence of making troubleshooting basic network connectivity harder than I can ever remember it being. Let’s review the list of things that could be wrong in a normal vanilla DHCP enabled IP LAN: