Sean Convery

Zeus Kerravala at Yankee has a nice column at Network World on the opportunity around network, identity, and policy integration. He writes:

Ultimately, getting policy to reside in a central location is the key. Rather than many disparate systems with policy information, enterprises need to have a single policy store, intimately tied to the identity store, where the network infrastructure can apply and enforce policy on all traffic. Having policy management in the core-with control at the edge-is the only scalable model for pulling together network, identity, and policy.

It is great to see more folks in the industry coalescing around this idea. The only thing I might take issue with is his goal of a single policy store. While that might be the best-case design ideal, I think the real world will require a much more collaborative approach. This is part of the reason my company writes all its policies using XACML. We’re expecting the need to share policy over time.

Technorati Tags: identity, policy, security

As frequent readers of this blog will no doubt expect, I was completely unsurprised by the shutdown of Lockdown Networks last week. Following the fire-sale of Caymas Systems and the announced restructuring of Vernier Networks as Autonomic Networks, it is natural that more NAC vendors would fall. Coincidentally, I was on the phone with a customer looking to swap out their Lockdown products for something more robust just before I heard the news.

For some analysis, take a look at the blog posts from Jon Oltsik and Eric Ogren, two former-colleagues of one another in the analyst community. The two take very different views with Jon pointing to Lockdown’s retooling of their product as a reason for their failure (but maintaining that the NAC market is healthy) while Eric blames the NAC market in general and the difficulty competing with Cisco and Microsoft.

I think Jon has things more on the money. The classic device-centric NAC market is crowded and with so many players it is awfully hard to reinvent yourself and still stay competitive. Part of me is surprised it has taken so long for another vendor to fail. After all, Cisco announced its intent to purchase Perfigo back in October of 2004. Perfigo’s product became Cisco Clean Access (the giant of the fledgling device NAC market). Lockdown’s technology seems almost identical to Perfigo’s but the market has moved on since then.

When I talk to customers I continue to hear the same themes as I did back in 2005 when I joined Identity Engines:

• Organizations want to use the network enforcement gear they already have
• No one wants to deploy a new inline device in their existing network (support and cost issues are cited)
• User identity is far more important than device health because it allows for far more fine-grained access decisions
• Guests and contractors is the area of greatest security concern
• Proprietary clients are a no-no

802.1X is the natural antidote to these desires and now that the deployments are getting larger and the technical objections are being removed through better solutions, I think we’ll be hearing a lot more about 802.1X this year. In fact, tying back to the Lockdown news you can see evidence of this in the market as a whole. Lockdown’s non-Cisco competitors are now talking a lot more about 802.1X and trying to bolt-on more of this type of functionality into their existing non-802.1X offerings. For a sense of this trend, look at the acquisitions in this space since Perfigo. We have Juniper acquiring Funk Software in November of 2005 and Cisco acquiring Meetinghouse Data Communications in July of 2006. The main technology asset of both companies was, you guessed it, 802.1X capabilities.

Technorati Tags: 802.1X, NAC, security

If you would have asked me two years ago if my company’s products would be broadly deployed by large universities, hospitals, and government I would have said yes. As expected, these types of customers have deployed our products and are starting to get quite sophisticated in their use of authenticated networks. However, if you would have suggested that community colleges would have found our offering compelling I might have though you a bit crazy. However, much to my surprise, community colleges are deploying Identity Engines’ products (and authenticated networks in general) regularly.

If you think about it for just a moment, it makes perfect sense. Community colleges have among the highest user turnover rates of any type of organization; thousands of users are often coming and going each semester. The faculty at these colleges is often a mix of full-time staff and part-time instructors with day jobs in the marketplace. Additionally, most community colleges have multiple campuses through a geographic area and need to coordinate access policies among them. Guest access is another key requirement as community colleges engage with the residents of their host city in a significant way.

Kevin Jones of Metropolitan Community College (MCC) and I recently gave a talk at the League of Innovations CIT 2007 conference. This is a conference focused on community colleges and their unique IT needs. We discussed MCC’s deployment of authenticated networks and delivered the presentation to a standing-room only crowd. So much for convention wisdom…

I recently had a short piece published in the Fall issue of the ACUTA Journal. It doesn’t look like they make the journal available to non-members but I got permission to share just the portion that I wrote. It is a high-level summary of role-based access control (RBAC) and how it relates to some of the emerging regulatory requirements for higher-education networks. Here’s the opening paragraph:

As recently as 10 years ago, we had it easy: Users stayed put at desktop machines, IP addresses never changed, and IT wasn’t on any lawmaker’s agenda. Solutions focused on the threats of the time, which, compared with today, weren’t many. But now technologies and threats are changing so fast that it’s hard to keep up. We can no longer count on a fixed IP address or even on a single device for a given user. We all want network access from the increasingly large pool of devices and access methods, and this has dramatically complicated the security task.

Technorati Tags: AAA, Identity Management

I’m pleased to relay the news that a development version of XSupplicant (an open source 802.1X supplicant) is now available for download. The OpenSEA alliance formed a while back and this is some of the initial results of the group (well really the talented developers of the Open1X project within OpenSEA). While this is most definitely a development release and should not be used in production, the developers are actively seeking feedback. So if you have the time and interest, they’d love any comments you may have.

Technorati Tags: 802.1X, Supplicant

John Roese, Nortel’s CTO, has a nice post on why he thinks we are almost at the point where enterprise network infrastructure can go wireless only. He’s careful not to say we’re exactly there now, but certainly sees Nortel as a leader in this space. He writes:

It is our position that, after a decade of evolution, both Wi-Fi and broadband wireless (4G) technologies are getting close enough to the expectations of the customer that we are becoming able to build the Unwired Enterprise from an access perspective.

I’m seeing this as well, though I think wired will be around for a long time to come. At Identity Engines, we have a prominent enterprise customer that finally decided to deploy wired at a new facility only because the VoIP quality wasn’t yet there for wireless. Furthermore, our experience in the education market shows that wireless only is already here in principle for many university students and staff; these university users frequently never connect to the wired network, even in their home location. The next several years will be interesting indeed, Roese thinks they might even shift the vendor landscape:

This is great for mobility and productivity from a customer view, but it is also an inflection point that can force a re-thinking of the enterprise LAN architecture. That is something that happens very rarely but, when it does, the market can be remade and the vendor landscape can be transformed.

I tend to agree but I think it might cause more of a trend towards commodity, standards-based, network infrastructure coupled closely with robust identity management for the network. Then again, I could be a bit biased in this regard…

Technorati Tags: 802.1X, wireless

Part two of a two-part article titled Network Authentication, Authorization, and Accounting was just published in the Internet Protocol Journal. I wrote the article to be a survey of the entire AAA space and so it covers a lot of ground without spending too much time in one place. If you are new to AAA or are looking for a conceptual model of AAA to help others grasp its concepts, please take a look. Here’s a snippet:

Network Authentication, Authorization, and Accounting has been used since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And finally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. The first part of this two-part series focused on the overall concepts of AAA, the elements involved in AAA communications, and high-level approaches to achieving specific AAA goals. It was published in IPJ Volume 10, No. 1. This second part of the series discusses the protocols involved, specific applications of AAA, and considerations for the future of AAA.

Although AAA is often thought of as the exclusive province of the Remote Authentication Dial-In User Service (RADIUS) protocol, in reality a range of protocols is involved at various stages of the AAA conversation. This section introduces these AAA protocols, organized according to the parties involved in the communication. We divide AAA communications into the following categories: Client to Policy Enforcement Point (PEP), PEP to Policy Decision Point (PDP), Client to PDP, and PDP to Policy Information Point (PIP).

You can get the HTML or the PDF.

Technorati Tags: 802.1X, AAA, IPJ

The IETF draft I’ve been tracking that defines a common format to communicate IP ACLs via RADIUS is now an official RFC. 4849 has a nice ring to it, hopefully it will become part of the networking and security vernacular like 1918 or 2827. Remember the RFC doesn’t mean anything until the industry builds support into its products. If you are a customer of Cisco, Juniper, Nortel or any other networking vendor I encourage you to ask for RFC 4849 support as soon as possible. Supporting it makes sense in almost all access devices: firewalls, wired switches, WLAN APs, and VPN gateways. Enabling role-based access control throughout your network is becoming less of a dream each day; RFC 4849 gets us one big step closer by defining a mechanism to support ACLs in heterogeneous network infrastructure. Here’s the abstract, scary that I get excited by this stuff:

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588.

Technorati Tags: AAA, NAC

With the announcement of OpenSEA and some new announcements from my company, I’ve been away from blogging for a while. Plenty has happened while I was gone. First, Microsoft and the TNC announced that a core NAP protocol would be part of the TNC. Second, OpenSEA got great press and we’re seeing lots of interest from new companies in joining. Finally, Caymas Systems went under making at least one of my blog predictions for 2007 correct. Each of these probably warrants its own post and I hope to get to each soon.

Technorati Tags: 802.1X, NAC, OpenSEA

Today I am thrilled that the formation of the OpenSEA Alliance has gone public. We’ve already had some nice press coverage. OpenSEA (Open Secure Edge Access) formed to promote the development of an enterprise-grade 802.1X supplicant. We’re basing our work on the existing XSupplicant. The founding companies are Extreme Networks, Identity Engines, Infoblox, Symantec Corporation, TippingPoint, Trapeze Networks and UKERNA. Jon Oltsik and I blogged about this a while back and this is the result of Jon’s efforts to corral the right industry players to make this happen. I’ll follow up with another post once I’ve had a chance to digest the industry reaction. For now, the FAQ has lots more information.

Technorati Tags: 802.1X, AAA, NAC, Supplicant