Sean Convery

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

With the college basketball men’s national championship game tonight, Network World posted a cute article outlining some statistics on both school’s networks. Worth a quick skim at least. Interesting bit of info on the anticipated size of the OSU network:

We are actively building out a Wi-Fi network on the Columbus campus that will reach over 300 buildings, 25 million square feet, and 1,700 acres. The network could scale to 10,000 access points and support 100,000 simultaneous users within five years. Currently we have over 2,500 Aruba access points installed, with 100% of our residence halls covered with wireless. The network is being designed to support 802.11a/b/g and voice services.

Technorati Tags: 802.1X, wireless

Though I’ve been too busy at work to read through this, the first draft of requirements for the IETF’s NAC is now out. It was written by a small subset of the working group and is just starting to get comments. If you are interested in checking out how the requirements are being presented, take a look.

Technorati Tags: NAC, NEA

Since so many other bloggers are having fun sticking their necks on the line with New Year’s predictions, how can I resist? There’s something about appearing sage–while knowing you can’t get called on your mistakes for 12 months–that is fundamentally appealing. Here are my predictions for 2007. Some of them are somewhat difficult to measure so I’m hoping to get some help from my readers this time next year on how I did. I’d love to see your own predictions as well in the comments to this post.

1. NAC as a term will grow out of favor as NAC teeters on the brink of Gartner’s “Trough of Disillusionment.” This one seems quite likely given that we have already seen a bit of NAC backlash. I can see this going a couple ways. First, rather than the NAC term completely going away I can see it surviving with qualifiers such as “Identity-based NAC.” Another option is that the term itself is completely replaced with something either more generic, or more specific such as network identity management or role-based access control.
2. One of today’s NAC vendors will go under. I don’t see how the market can sustain so many players, especially given that some have seen many rounds of funding and have already retooled their products once to chase the NAC wave. I won’t list all the NAC vendors here but there are easily 15 or more.
3. So that I’m not all doom and gloom, one of today’s NAC vendors will get acquired by a larger firm. Whether the NAC term survives or not, the functionality of NAC–in its broadest definition–is useful to organizations. There are plenty of players who need that functionality in their product portfolio. My guess is a networking player will do the buying. I won’t get into whether the acquisition will be from a position of strength or as a result of the NAC vendor running out of cash, but it is fair to say that both appear feasible.
4. An open-source 802.1X supplicant will emerge as a viable alternative to commercial and OS-native supplicants. So that I don’t give myself any wiggle room here, this doesn’t mean that one is available to download, but rather that organizations are deploying it at scale. I think the market can’t help but make this happen since the OS supplicants are lacking and the commercial supplicants are simply too expensive. Think of the market forces that created Firefox when Internet Explorer wasn’t getting the job done; I think we’ll see something similar here.
5. 2007 is the year wired 802.1X turns the corner from rare occurrence to early-adopter chic. While it won’t be mainstream by any means (that label will belong to wireless 802.1X) it will see substantially more deployment than in 2006.

Technorati Tags: 802.1X, NAC, Supplicant

Just a quick update on NAP. Microsoft has announced that they will be adding an XP NAP client that will speak 802.1X–in addition to the other NAP protocols like DHCP and IPsec:

Some other cool news, never before discussed publicly. We are adding 802.1x NAP Client support to XP for both Wireless and Wired connections. I am really excited about offering this to customers on both Vista and now XP. I hope to release a Beta of this functionality in early 2007. This brings the XP NAP Client into full parity with Vista supporting IPsec, DHCP, VPN and now 802.1x.

I wonder if this is a small sign that Microsoft wants to take 802.1X on wired a bit more seriously. It could be an offshoot of the relationship between Cisco and Microsoft on NAC/NAP as well.

Technorati Tags: 802.1X, NAC, NAP

Cisco has announced the branding of the Meetinghouse 802.1X supplicant. The “Cisco Secure Services Client” is now available. I wrote about the Meetinghouse and Cisco deal a while back. I was right when I predicted that Cisco would pull Meetinghouse out of the TCG / TNC; that happened pretty fast. However, I was wrong when I predicted that Cisco might sell their client for substantially less than Juniper’s offering or even give it away for free. My reasoning was that Cisco had far more to gain by selling switch migrations enabled by a supported supplicant, than they did in trying to recognize revenue per seat in connecting to those switches.

I still stand by that. However, there is some subtlety here. just because something costs between $30 and $40 a seat depending on volume (very similar to Juniper’s supplicant), doesn’t mean that Cisco will charge that to its biggest customers. The minute a major account manager has a giant Catalyst switch deal on the line if they can remove the supplicant objection, I think the cost will be reduced if not eliminated. That’s just good business.

However, if Cisco’s goal was to ensure that 802.1X succeeded only on Cisco kit, their strategy seems more plausible but is still flawed. A Cisco supplicant which was almost free to Cisco networking customers but not for anyone else would prevent non-Cisco network customers from freely using the Cisco supplicant. The flaw comes in with respect to 802.1X’s wired deployability in general. Cisco succeeds when the network gets more intelligent. 802.1X is still in its nascent stages on the wired side and Cisco’s competition isn’t really HP ProCurve (regardless of how much HP would like that to be true). Their real competition is dumb networks in general. Vista’s security infrastructure doesn’t require the use of networking as enforcement. It doesn’t have the 802.1X supplicant complexity as a required element. While their security model is incomplete, it is also mostly free to organizations deploying Microsoft on the server and client side–which is just about everyone. For more evidence on Microsoft’s stance on wired 802.1X see this article which was originally titled “802.1X on Wired Networks Considered Harmful.”

Rather than trying to differentiate Cisco vs. the other network vendors, Cisco should instead be trying to rally the networking industry to compete with the onslaught of host and application oriented security solutions. I’ve often stated that security is a system and that there are roles for the network and the host to play. However, business goals and security architecture aren’t always aligned. Cisco should be championing open standards to make the network more intelligent, not looking for ways to keep such systems proprietary. They already have the market share and if customers see them as innovators and embracing standards (which is how Cisco got to where it is today) they will continue to buy Cisco. This bears on their supplicant pricing decision as well as their involvement and willingness to drive standards around NAC.

When IPsec VPNs for remote teleworking became viable, Cisco bought a company called Altiga. Altiga became the Cisco VPN 3000 Concentrator and it was quite a success. The client for connecting to the concentrator was given away since the money they wanted to make was in the hardware. However, there were proprietary extensions to the client from Cisco and other VPN vendors like CheckPoint and Nortel. Microsoft had their own IPsec client in Windows, but because its configuration was clunky; it wasn’t used. IPsec never really converged on a standard, open, and interoperable client. As a result, SSL VPN seems to be the technology with long-term staying power in no small part due to the client being ubiquitous. With 802.1X / NAC, Cisco has proprietary technology and is charging for the client. I’ll be surprised if the outcome is better and not at all surprised if it turns out worse.

This further reinforces the need for an open supplicant as I’ve wrote about before. The next 18 months will be very telling for 802.1X as a ubiquitous authentication mechanism rather than a deployment necessity for secure wireless.

Technorati Tags: 802.1X, Cisco, HP Procurve, NAC

Ed Vielmetti’s daily del.icio.us post alerted me to an ancient (in networking terms) article on visitor networks and various strategies for their deployment. It was published in Cisco’s Internet Protocol Journal back in 2002 and it is surprising how much the technology for deploying visitor networks has not changed. The core goal of being client-less remains and the techniques around captive portal are still very much in use today. This is great background information with plenty of application in today’s authenticated networks.

Technorati Tags: identity, guest networks

Along with HP’s support of 802.1X in its printing line comes Lexmark with its own announcement focused on federal security requirements. I’d really like to see more data from customers deploying wired 802.1X, but more support within the devices itself is not a bad thing.

Technorati Tags: 802.1X

Jeff Boles writes this about NAC:

What we should be left with in NAC is an evolutionary development of current architectures, such as 802.1x, that are standardized and fully interoperable. There’s some discussion afoot about interoperability, but in reality the market has greatly fragmented itself with a bunch of different solutions and poor definition of what NAC is. We’re left without a solution set, but a lot of different packaged up products.

I think Jeff has this right. Cisco, Microsoft, and other big players have often touted proprietary protocols as a way to seed the market with an in-demand capability. Cisco did this correctly with the Hot-Standby Router Protocol (HSRP) and with some of its early extensions to IPsec. However, 802.1X is relatively new without being further encumbered by NAC. Cisco sees this and has begun positioning Cisco Clean Access as an alternative to 802.1X-based NAC.

While there seems to be widespread agreement that standards are necessary to get a functional and interoperable NAC architecture, standards are slow going. The IESG within the IETF finally received a submission from the Network Endpoint Assessment (NEA) mailing list to form a working group today. The chairs of the mailing list are representatives from Cisco and Juniper, two companies with substantial stake and influence in how all this shakes out. While I hope specifications move more quickly than the initial formation of the working group did, I’m not hopeful that the IETF’s sluggish tendencies can be easily remedied.

Technorati Tags: 802.1X, NAC