Sean Convery

Somehow my old RSS reader missed a whole series of Radovan Semančík’s posts. (On an aside completely unrelated to the topic of this blog, NewsFire for the Mac is grand.) I came across a great entry Radovan made from back in May describing some of the reasons why organizations will be hard pressed to merge onto just one directory server and also some interesting points on why a directory server is not an authentication server. (Gratuitous marketing plug warning.) We put a lot of effort into the multi-directory connectivity and attribute mapping capabilities of our Ignition platform here at Identity Engines. It is nice to see some more evidence on the outside that this was time well spent.

In my customer interactions I see some of what Radovan posted but also see a common business reason for multi-directory: the rate of mergers and acquisitions in large enterprises today is high. As new organizations are integrated into the IT fabric of the acquiring entity, there is often a reasonably lengthy period where the directories remain disjointed. By planning your directory infrastructure and related AAA functions around the assumption that you will always have more than one directory it can lead you down a network architecture path that is significantly more flexible over the long term.

Gartner released a small report outlining the implications of Cisco’s acquisition of Meetinghouse titled: “Cisco/Meetinghouse Deal Weakens NAC Standardization Efforts.” The report is summarized in a ComputerWeekly article which is the best place to read about it if you don’t have access to Gartner’s research directly. Gartner is anticipating much of the same events I wrote about earlier this month: namely that Cisco will pull Meetinghouse out of the TCG-TNC and there will be no more independent and commercial 802.1X supplicants on the market. To quote the report’s summary:

Acquiring Meetinghouse will round out Cisco’s 802.1x offering. But recognize that deploying a Cisco supplicant will likely require you to commit to a full Cisco Network Admission Control implementation.

It will be interesting to see if the second NEA BoF at the recent IETF meeting is successful in converting to a working group. If not, I’m not sure what this says about NAC standards in the mid-term. You can read the minutes here.

Eric Norlin over at Digital ID World is posting a bit lately about the identity elements of network access control (NAC). First making the case for identity being a component of NAC and later describing why static roles don’t cut it once you go beyond very basic policy with NAC. (Full disclosure, I’m speaking on a panel at this year’s Digital ID World about this very topic.) If you’ve been following the identity management space at all there is an implied prefix for almost all discussions on the topic: the word “application.” Whether it is single-sign-on, federated identity, or two-factor authentication; nearly all topics related to identity management are framed with respect to the application. This makes sense after all, as it is the application that is the only place–save a VPN connection–that a user has typically authenticated to.

This lack of focus on the network can be entertainingly exposed through a few google searches. Google (in quotes) “application identity management” and you’ll find a paltry 120 hits with both Eric’s and my passing use of the term on the first page. Google “network identity management” and the situation improves with about 10,400 hits. Now google “identity management,” the term typically associated with “application identity management,” and you get a number more like what you’d expect: over 35 million.

Times are certainly changing though as now Digital ID World, long a stomping-ground for the practitioners of identity management as traditionally defined, is taking on NAC. This either strikes you as intuitively obvious or completely wrong depending on your frame of reference. NAC as it was originally trumpeted by Cisco and others focused in on a very specific, albeit novel, application of NAC: validating the configuration or “posture” of an endpoint prior to connecting to the network. This functionality was called “network-node validation,” “posture checking,” and other similar terms. For obvious reasons given Cisco’s marketing budget, these checks became synonymous with the broader use of the term NAC.

However as Eric points out, NAC is anything but just checking patch levels:

Walking through NAC reveals this to be so: a person (identity) authenticates to a device (identity); device (identity) authenticates to the network (identity); network checks device for policy compliance - often individual specific policy compliance(identity); network enforces compliance upon person through a series of challenges, alterations to credentials or revocations of access to critical systems (all identity); network aggregates all identity data around devices, policies and individuals for audit purposes (who had access to what under what circumstances for what reasons and for how long — all identity); network helps person and device correct any policy violations (identity) and begin accessing (identity) applications with fine-grained authorizations (identity).

“Identity Management” is certainly the correct term without the prefix but it may take us a little time to get there. One practical impediment is that the network operations folks looking at identity are generally not the same people that would deploy a single-sign-on service for an enterprise’s web applications. However, these barriers need to be torn down because the potential applications are quite compelling. For example, imagine checking the integrity and identity of a laptop prior to allowing it to originate transactions above a certain dollar amount within an enterprise’s accounting system.

Until then, I welcome these early conversations concerning extending identity management to the network. NAC probably represents the best bridge between these two worlds and I look forward to more discussions with the application folks over time.

Firefox rose up and has challenged IE in the browser wars. In the far more esoteric supplicant wars there has yet to be much of a battle at all. The Open1X guys have XSupplicant but I haven’t yet heard it seriously considered in an enterprise deployment. Most of the OS vendors have their own supplicants but these are not consistent in their operation or their supported use-cases. Cisco now has Meetinghouse, and Juniper picked up Funk a while back. This leaves no viable supplicant without OS or equipment vendor alignment. While I hope Meetinghouse and Juniper stay vendor neutral, the industry certainly shouldn’t count on it. I wonder if some bigger vendors like Novell threw some dollars / developers at the XSupplicant guys, could we get a viable open source supplicant in the market fairly quickly? It wouldn’t see deployment in the next few months but then it took a while before Mozilla became Firefox.

Yesterday Cisco announced its intent to purchase Meetinghouse, the only remaining 802.1X supplicant vendor in the market after Juniper’s recent acquisition of Funk. As Wi-fi Net News notes, this thins the RADIUS market even further (though it sounds like I should get my marketing department in touch with the author–Glenn Fleishman–for a product overview). Overall the acquisition seems like a significant positive for Cisco for a number of reasons. There are also some considerations for the industry as a whole. Let’s cover Cisco first.

First, Cisco now has a multi-OS supplicant they can provide to their customers to help remove objections to new wireless or wired infrastructure deployments. They achieved this goal for significantly less money that Juniper did with Funk (44 vs. 122 million) in part because Meetinghouse did not have a significant presence in the AAA server space the way Funk did with its SBR. Since Cisco has their own AAA server in ACS, this wasn’t a significant issue in Cisco’s eyes.

Second, it appears that Juniper is attempting to take control of the edge access methods within an organization through either their SSL VPN products or the 802.1X supplicant. Since they have neither Ethernet switches nor wireless APs to sell, they recognize revenue on the supplicant. Cisco on the other hand, has both switches and WLAN APs allowing them to use their new supplicant as an enabler potentially by giving the client away or offering it for substantially less. Assuming that Cisco continues to commit to standards, having a freely-available and well-supported supplicant in the marketplace would be a great thing.

Third, by being in control of the supplicant rather than using an OEM Cisco can have complete control over the roadmap ensuring that the supplicant does what is needed for both WLAN and Cisco NAC.

Moving onto the industry implications things get a bit more muddy. First, I think this will be a net positive for 802.1X deployment but I’m not certain which way Cisco will go with respect to keeping the Meetinghouse supplicant open. If they go the route of a free supplicant, what motivation do they have to make sure it supports the EAP-types and unique parameters of their competitor’s gear?

Speaking of standards, the TCG TNC could be adversely affected. The TNC has been around for a couple years now and hasn’t yet seen a ton of traction. Up until May’s Interop conference, Juniper was the only announced and shipping TNC server. At Interop, Meetinghouse announced an appliance which was set to be the second TNC server though it has no definite ship date to customers. Since Cisco seems to view the IETF as the only viable forum for standards in this space I would not at all be surprised to see Cisco end Meetinghouse’s engagement with the TNC and kill the announced appliance. This would leave the TCG TNC effort as primarily Juniper and friends. Looking at the announced and shipping products list on the TCG website it looks quite thin.

As stated several times on this blog, 802.1X is hardly the runaway success it hopes to be, at least on the wired side. Cisco themselves are pushing the NAC appliance more than the 802.1X approach anyway which diminishes the implications of much of this. Until the industry gets some agreement on a ubiquitous and standard tunneled-EAP type as well as some standardization in messages and frameworks many organizations will be left to put together ad-hoc solutions which may not hold out for the long haul.

Companies can recognize significant value from authenticated networks today using a mix of authentication methods including 802.1X. The benefits of centralized policy decision and network compartmentalization are real. The key is to avoid going into this thinking that it is a binary event to turn on 802.1X. As mentioned earlier, making good use of the default VLAN feature can give you a migration path which doesn’t seem quite so vertical.