I’m presenting later today at the New York Tech-Security conference on identity-centric NAC. This is following the same theme as my remarks at Digital ID World. You can download the slides here. Comments welcome as usual.
-Special thanks to Roy Chua for taking notes on this session I participated in on Tuesday-
Panel
ESG
- Jon Oltsik – introducing
ConSentry – Jeff Prince
- Secure internal LAN, not rip replace
- Full user visibility and mitigation
- Here – identity key to their closing of businessSanjay Uppal – CEO of Caymas- Identity control appliances
- Have been doing for some time now
- How it all comes together, two important categories coming togetherSean Convery – CTO of Identity Engines- Network identity management platform
- User is center of identity in enterprise
- Bring user directories to the network – to make meaningful decisions
- Works with new devices as well as existing equipmentPaul Sangster – Chief standards officer at Symantec- Security and integrity protection for enterprises
- Co-chair of TNC group
- Working on NAC open standards
Definition of Network Identity
Paul Sangster
- establishing set of attributes with regard to things on network
- From NIC card to laptop to human
- And authorized to get on network
- Identity – ties into integrity and event managementSean Convery- Network ID used to be MAC and IP addresses
- Talked about spreadsheets and IP = user
- Mobility has made MAC and IP more difficult
- Seeing prevalence of user-centric identity
- From simple auth to 802.1XSanjay - Practical and then future
- 2-factor, client certs – one aspect
- Other aspect – integrity of device – combination of multiple ID
- Practical – integrity of device
- User – username, password, token
- Future – combination of twoJeff Prince- Knowing users and machines connecting to network
- Trick (as Sean put) – bind users to IP and MAC
- How to make user-readable, and location-based – bob, using machine X in office 12
- Location is important as wellCisco and MSFT were invited to participate but declined
Jon: implementation is difficult
Many supplicants, devices, EAP strategies
What to help people ease into solution
Jeff Prince
- Been in networking long time
- Things that become pervasive on network – easy to deploy, cost effective, high performance
- Cisco NAC – good vision, impossible to implement
- ConSentry want to execute that vision – e.g. rip out L2 switchesSean Convery- Cisco not quick to release NAC specifications
- Seeing lots of interest in preserving infrastructure built out
- Seeing disparity in making enforcement technologies
- From enterprise – deploying 6, 8, 10 different things – hard
- Need central authoring and policy point
- Trying to put all eggs in one technology basket is troublesome long term
- Particularly due to lack of standardsPaul Sangster- See difficulty in deploying – e.g. AV, desktop FWs – people turning it off
- IT needs centralized point of control – and when joining, want to make sure that the machine is healthy and to do so periodically
- Customers tell them this is very difficult but customers don’t want to take the wrong step – don’t want to step up until see long term future of spaceSanjay Raja- Agree that Cisco and MSFT is not open enough
- Don’t agree with vision of NAC – network admission control
- Customers are asking, after you get admitted, where can you go
- Shouldn’t be limited to just network, but applications as well
- NAC should be access control done in the network, as opposed to, to the networkJon: who supports TNC, and why hasn’t everyone in audience heard of it
Paul Sangster
- Communication – Cisco and MSFT have large PR budget and voices
- TNC – many large companies, focused message is hardJeff Prince- Biggest frustration – CSCO not member
- Own 80% not adhere to standard, neuter standard
- User community put pressure on CSCO to join
- Best way is to drive standards between endpoint and networkSean Convery - Not failure of TNC
- But failure of any architecture for NAC overall
- Have had problems deploying NAC framework at Cisco
- Customers are coming and saying NAC with AV, and firewall and .dat files are good
- Want to know who’s coming on network first, and then along with everything elseSanjay Uppal- Agreed, how to integrate client with network
- Should have defined protocol for not 802.1X but others
- Captive portal and web-based login first, and then do bells and whistles
- Need an open supplicantJon: trying to rally around the open supplicant- MSFT, CSCO, Juniper – proprietary – how to drive open supplicants
- Good grassroots support to date – www.enterprisestrategygroup.com
Question from audience:- Why won’t people stay with MSFT and CSCO and wait until they are done rolling outSanjay Uppal- Most of their customers (e.g. Hormel), waiting for Longhorn or CSCO, a lot to ask for from people with problems today
- Already have problems with identity theft and guest users
- Products on panel will solve that today and don’t have to wait till giants learn to dance
- For entire infrastructure though, advice is to waitPaul Sangster- Normal enterprise risk analysis decision
- Lots of data on cost for enterprise for not being able to enforce decisions about posture (worms, malware etc)
- Don’t want to make bad decision, need future proofing
- Nature of attacks over last 12 months, more focused on enterprises
- Without integrity checking, lots of enterprises have user auth, nothing to stop malware
- Need to have no malware stealing credentialsSean Convery- Agree that solving acute problems today
- Biggest people deploying our product have short-term access problems
- When talking about NAC and are people ready to deploy NAC
- NAC is AAA
- Dialing into POP over SLIP – using AAA NAC back then
- Principle reason we exist – authenticate people on network
- Repository of user identity and not treated as a critical resource on network
- AAA down – lose VPN and wireless
- Moving forward, how do you authorize users to get on networkSanjay Uppal- On aspects of what customers should do from a practical standpoint
- Non-employees getting on network – biggest risk
- Yesterday – SLIP connection – had today, but need combination of identity of user and device as well (e.g. folks in India and Philippines doing contract programming)Jon:- How much marketing money CSCO has? LotsAudience: where’s the vision for centralizing policies throughout the company . Don’t have the people – geeks on parade. Don’t want to call someone to make change in some device. How to go I to a central policy store to make these changes across enterprise-wide.
Jon – paraphrase – centralized policy instead of policy everywhere
Sean:
- Think we have won’t have centralized policy today, and may never, but some day
- Trying to embrace standards around this area – e.g. XACML around that, SOAP-based interface
- Work on networking problems first, and then start doing it for the applications-side, assert it to the futureJeff:- See solution boiling down to three basic components:
o End point, control piece in switching infrastructure, and IdM infrastructure
o Defining standards – is critical
- Today, ConSentry built controller behind the switches, can’t rip and replace everything
- As people do switch replacement, will see it coming in
- Announced secure switch, embeds full function into wire-speed switchSanjay Uppal- From enterprise, have concern about adding more layers
- Don’t want new policy in AD, RADIUS etc
- There are standards for asking about Identity – not rich, but can work
- No standard way to ask for policy yet
- Also need standards to federate health
- Once standards set – one place to set policy to get management policy (not appliance), and enforcement can be switch or not, think appliance is still important, need client piece as well for integrityPaul Sangster- Centralized place for policies
- Everyone has that, but then you still end up with many centralized stores
- Need MetaDirectory
- Need a PDP that can talk to other PDPs or network
- Can express PDP in some form and push it out (e.g. XACML)Jon:- See standards – e.g. Federation, users have to drive big vendors on TCG and 802.1X
- Will have more IP devices, no vendor at all, including CSCO, MSFT, that will give us what we needAudience:
Qn: focus on LAN and enterprise network, WiFi LANs, services networks etc
Federated model with common security model, tying in all the items, e.g. DS_69 on DSL forum, is important. Standards from wide area, to LAN to core etc.
Is there integrated architecture, for LAN, WAN, Service Provider etc?
Paul Sangster
- Don’t want different infrastructure for all – how to come up with extensible portion across all networks
- Access points for WiFi to talk to RADIUS
- Maybe not needed for LAN over cable
- Backends need common infrastructure – TNC identity all common areas
- Have laid down protocols for bottom layer for some areas already
- Pushing that TNC can cover it all as a high-level infrastructureSean Convery - When we say appliance, means different things to different people
- Goal of IDE is to work with different types of devices
- E.g. FW, switch etc
- Aggregation to get all these things talking
- RADIUS got us on 99% of access decision today
- Some disagreement – position – rich decision made in one place is good, but also want consistent set of entitlements in terms of what you’re allowed on
- But can only do that with standards - so there is limitation
- Even insertion of a device everywhere is close to rip and replaceSanjay Uppal- NAC is not limited to LAN
- Disagreement – their device can check local area network and wide area
- Perimeter is disappearing but they are appearing elsewhere
- It is not just LAN, but also where users are coming in from Jeff Prince- No reason why they can’t span LAN and WAN
- Once solve problems for LAN, then can solve problems for WAN and other places as wellAudience – TNT - Practitioners here – don’t wait. Even TCG/TNC will take time
- There are problems now, and people are buying equipment that the vendors are buying
- Forward thinking folks don’t care and will solve the problem now
- ‘Who is buying the stuff now’
- What position, what problem solvingJeff:- Customers are driven by compliance – PCI compliance in 3 weeks
- Passed audit within 3 weeks
- Regulated folks – HIPAA, PCI, SOX – folks with corporate assets on LAN
- Prove have clamped data need now
- Compliance is not done yet (still real today)Sanjay:- 1. There is a compliance push out there
- No one is making be-all and end-all of compliance solution
- Have one, pass all, no compliance in a box today
- Can implement these much quicker
- 2. Business enablement – e.g. outsourcing, make sure people only get access to specific areas. Not security value-prop, but business value-prop
- 3. Risk management – ID theft, laptops getting stolen, CIOs want to lock down sensitive information, criminal or other records
- Identity-based NAC to deal with thatSean:- Biggest problem – contractors, guests, visitors – that we are solving right now
- Keeps customer excited longer term
- Flexibility of policy
- Organizations have directories all over – really useful information – meaningful access decision
- E.g. Library at university that wanted low QoS for overdue customersPaul:- Apply political approach
- He is a standards person
- TNC – no standard, but people have standards-compliant products?
- Going out and taking RADIUS and using it
- Using EAP and if doing 802.1X, already have it
- TLS, IPsec, doing standards over
- Have to have a common way do the same thing, protocol standards already existJon: 7 minutes left – Lightning Round
Audience: so, who is the buyer?
Jeff:
- Security is champion, but the network ops guys is the one buyingSanjay:- Security guy signoff- app guy if app resource, or networking guy if network resourceSean:- network and security guysPaul:- samePapa Gino’s – audience, Chris Cahalin, Network Manager
Qn: $ spent towards unified standards is $ saved
-TPM already exists on laptops – march 2005 – have been using it
- Facilitates business
- Backs TCG
- Extends end-point analysis, can you trust the response you’re getting
- In deployment today
- Appreciates open standards
Jon: closing thoughts
Paul:
- too many NAC, tell vendors that want one open solution, can start today
- Built on things already deployed
Sean:- Can start today
- Things that you can do that don’t require TPM or OTP
- User names and passwords insufficient is not reason
- Diagnostics etc are more significantSanjay:- Enterprises with business problem today – they have solution
- Audience in IdM space – combination will get thereJeff:- Clear alternatives to CSCO
- Get to secure LAN today with them
- Give them opportunity and show value
Here’s my rough notes from the first session, please expect the writing quality and grammar to be degraded. My comments / editorializing in brackets prefaced with “SJC”
Rob Clyde, VP of Technology, Office of the CTO
Phil Becker, Editor in Chief, Digital ID World
Phil: Identity in computing started with security
Rob: Looking at protection, what can we do to protect the information, interactions, etc. Attacks are now financially based. Identity theft is key.
Phil: Shift from locking things down to providing protection?
Rob: Yes, protection and confidence to allow folks to do what they want to do online
Rob: Lots of past business if focused on information and infrastructure, now focused on protecting the interaction
Phil: This also raises company’s confidence in what they are doing re: compliance / regulation perhaps?
Rob: Compliance is huge. Two pieces: 1. Comply with regs, 2. IT governance in general to provide competitive advantage. Sloan biz school found those with strong IT governance were 20% more profitable…
Phil: Why is that true?
Rob: Choosing projects carefully, linking IT carefully with the business
Phil: Compying with business vs. security outlook - lockdown is keeping people out, protection is opening things up to get what you need to get done.
Rob: Huge paradigm shift. NAC is a big shift. Cellphones are another. 15 yrs ago device choice was employer mandated, today, device is generally chosen by the employee / consumer. But still most of us need to use laptop defined by the employers. With policy frameworks, users can choose which devices they want at the laptop level provided they comply with policy [SJC, this sounds great but security is one of a dozen pieces around desktop operations, what about software licenses, support calls, etc., I'm not sure the endpoint platforms have the simplicity of a cellphone to make this viable. If desktops did just a couple things, this makes more sense. I'd like to see this in the future though.]
Phil: What about the dumb network vs. smart network debate?
Rob: Need to manage security via policy but trying to push support from the IT department to the end user itself…
Phil: What happens to categories in products themselves around security? NAC itself will reach across some of these boundaries.
Rob: One thing that will happen is a lot of interoperability. Lots of SIMs out there but big problem is IP address or process can be determined but that identity is much harder to determine. NAC + Endpoint compliance defines the “What” which is closely linked to the “Who.”
Phil: Any thoughts on how the evolution of this? What comes first?
Rob: 802.1X will drive this with endpoint compliance, NAC, and 802.1X. Slow uptake on 802.1X. Non-.1X is more prevalent today.
Phil: Could they unite at the identity store and management level first and then move down the stack?
Rob: No single identity store will happen, lots of stores long term but the exchange of information will be key.
Phil: Looking out at the world re: 802.1X, do you see the other protocols there to do the interconnection that is desired?
Rob: Lots of good ideas, many fairly immature. Most of work is around identity information exchange and SSO. Problem is how do you establish the identity in the first place? Broker-based identity? How can the end-user trust the server. Those are the though problems.
Rob: Easier for enterprises since they have to show up to get a badge and that could be leveraged moving forward. In B2C, this is harder. Many have stopped giving out information online. People concerned about websites stealing identities.
Phil: Is this where we need 3rd party broker?
Rob: Yes, we’re there on the money risk, but not the identity theft risk.
Phil: Security evolution requires identity management. Links between event detection and identity itself. How does this come together?
Rob: This has to come together. Security of exclusion has accounted for most of the revenue so far. Security of inclusion is the wave of the future. Need more collaboration, etc.
Phil: What is the wavefront of where the money is going which allows us to see this?
Rob: The nature of the threat is now more financially motivated. Companies are concerned about the insider threat. IT governance and regulation. These things cause this convergence.
Phil: Purpose of the network is to remove the concept of location as being significant. Network security has been about building perimeters which undermines the overall goals of the network.
Rob: Mindset that wants to go that way, but lots of mandated security, etc. People would like to see a different way. Perhaps making your internal network the Internet essentially using secure applications. Jericho is looking at this. 25% of help desk time is spent resetting passwords. Lots of additional problems, perhaps we need less IT over time for desktop support.
Phil: How can customers prepare?
Rob: How can I manage the network by policy rather than by specific configurations and mandated software. Look for apps that are more web based which protects things. This allows a smaller perimeter.
Phil: So people in the office are outside the perimeter just like remote workers?
Rob: Sure, just like a VPN connection. [SJC - The peer-to-peer issues here are huge. Hub and spoke networks sacrifice an awful lot of functionality and availability]
Technorati Tags: Digital ID World, Symantec
I called out a Kodak camera which supports 802.1X in an earlier post. Now Tandberg has a high-end video conferencing system which supports the protocol as well. Whether this can be taken as a proxy for increased corporate 802.1X demand or simply a manufacturer taking advantage of pre-built features in network stack remains to be seen. In even better news for 802.1X, this page at HP’s website claims their latest Jetdirect cards support 802.1X as well.
Technorati Tags: 802.1X
In early July, Jon Oltsik of Enterprise Strategy Group and I both blogged about the need for more emphasis on an open-source 802.1X supplicant. With Funk and Meetinghouse both being acquired by large infrastructure companies there is no other commercially supported 802.1X supplicant on the market. Turns out Jon and the folks at ESG have put more effort on this beginning with a paper describing the problem in more detail. I hope the right folks at possible sponsor vendors are reading it and reaching for their checkbook. It may be time for the Open1X Foundation to be formed (catchy marketing name forthcoming).
Technorati Tags: 802.1X, Supplicant
At Blackhat this year, Ofir Arkin (CTO of NAC vendor Insightix) attacks NAC. It would seem from reading some breathless press reports that major flaws and vulnerabilities have been discovered. The first article about this talk is from Dark Reading and was released almost a month ago. Here are a couple more recent from Infoworld, and Internetweek. Though I did not attend Black Hat this year I’ve reviewed Mr. Arkin’s slides. I have a number of problems with this entire brouhaha.
First, why are so few people reporting on the fact that Mr. Arkin works for a vendor which sells network access control products? In the Infoworld article the author makes no mention of this fact at all besides listing the company Arkin works for. Internetweek goes further by mentioning that Insightix is “an Israel-based developer of agentless, real-time IT infrastructure discovery and monitoring solutions.” Dark Reading is the only one of the three which tells the full story:
Not surprisingly, Insightix is offering products that could help close the vulnerabilities in NAC systems. The Insightix NAC solution, introduced three weeks ago, includes a network discovery tool that not only shows DHCP addresses, but static IP addresses and details on how clients and devices are connected to the network.
I’m no stranger to Black Hat–having presented twice–but both times I was listing design considerations in my own company’s products, not attacking my competitor’s approaches. This is grandstanding at its finest and I’m shocked that most of the media reports I’ve seen so far give Arkin a free pass. A quick visit to Insightix’s own website will make it very clear what role they see themselves playing in the industry.
Second, the posturing of this presentation to the press, to the Black Hat audience themselves, and what was actually delivered in the slides is quite different. First let’s compare a snippet from the InternetWeek article with the Black Hat abstract. First Internetweek:
“People need to understand that NAC is not bulletproof and that’s it’s something important that needs to be taken care of,” he [Arkin] says. “They might already have the right solution to handle their NAC issues, but they need to understand where to apply it.”
Pretty level-headed advice. Now the abstract:
Flaws associated with each and every NAC solution presented would be presented. These flaws allows the complete bypass of each and every network access control mechanism currently offered on the market.
Woah! This is clearly more incendiary and absolute in its damnation of NAC as compared with the press quotes. The grand claims in the abstract raise the question: what flaws were found which allow “the complete bypass of each and every network access control mechanism currently offered on the market?” Now again, I only reviewed the slides that were presented and heard from some of the folks in the room so some of this is conjecture (but hey, this is a blog right?). Since I haven’t seen the slides posted publicly yet, I’ll constrain this post to the flaws described in the press so that I can quote directly.
This leads me to point three: the flaws describes in the press–which should be among the juiciest–seem thin at best. Here’s a snippet from Infoworld:
NAC solutions that enforce access through network switches, such as Cisco Systems’ Network Admission Control, also have weaknesses, he said.
For example, Cisco’s NAC technology is specific to their switches and routers, but enterprises often use a mixture of switching and routing gear. Hackers can find their way into an enterprise network simply by finding and connecting through an unmanaged switch, he said.
Stop the presses; security controls don’t work on devices which don’t run them! Mr. Arkin is raising a very valid deployment concern which architects need to be aware of, but it reminds me of a deployment concern raised in the mid 90s around firewalls: If there are paths in and out of your network that don’t go through firewalls than your firewalls can be bypassed. Deployment concerns are not fatal flaws. However, there is a reason Arkin’s talk was titled “Bypassing NAC Systems” not “NAC Deployment Considerations.” First, as I know first hand, the Black Hat conference likes flashy titles. Second, so does the press. This is too bad because for the most part the information in his presentation presents useful design considerations around NAC as well as a substantial section providing an overview of NAC’s different approaches.
To wrap up, when evaluating a security control you should measure it against what you actually want to accomplish with it. As Mr. Arkin points out in his presentation, the definition of NAC is nebulous. Therefore describing ways to completely circumvent it seems confusing, even if he did point out novel techniques to do so. This is because without clear design goals and expectations, any system can be shown to fail simply by changing the target objective. This is why common criteria evaluations need to list what they say they protect against so that the measurement is accurate.
As I pointed out in a brief article from last year on NAC from a Cisco perspective, one of the most basic benefits that NAC can provide is to ensure systems that aren’t actively trying to subvert your security don’t become conduits in the proliferation of malicious code. Now I’m certainly no NAC zealot; I’ve written lengthy posts in the past on some of the challenges associated with NAC and I certainly agree that it has plenty of room for improvement. However, this and other elements of NAC’s functionality, have value which is in no way diminished by any of the “flaws” described at Black Hat. John Stewart, the CSO for Cisco (on the IT side of the company) said it well at the end of the InfoWorld article:
“The technology’s immature. But [NAC] will increase my capability to keep my network in good condition. Can it be maneuvered to have false data? Yes. Would it be completely the case that every device on my network will provide false data? Unlikely.”
“It’s inherently going to be found that there are weaknesses. But I think that’s the wrong thing to focus on. We want to address the weaknesses but focus on the benefits,” Stewart said.
I hope that as NAC moves along the adoption curve we can have level headed conversations about its use in networks and that the press, the vendors, and the researchers work together to find out the best way to protect against attacks. Eric Norlin’s more sober analysis is welcome. Also, I came across a very level headed article from earthtimes.org of all places which ignores the hype and just focuses on the useful info Mr. Arkin did present. This is where we need to head. After all, we all want a more secure network…right?
Technorati Tags: 802.1X, NAC, Network Security, Black Hat
Earlier this year I wrote about the basics of 802.1X with the default VLAN. I still believe it provides a great way to slowly coax users to 802.1X without forcing an instant migration as well as a nice way to integrate guests onto your network. Here’s an additional tip for how to work with the default VLAN when using a captive portal, I recommend reading my earlier post first if you haven’t already.
One wrinkle with the default VLAN has to do with DHCP and how tightly coupled it is with the 802.1X process. Ideally the 802.1X supplicant you use would automatically do a DHCP release / renew each time the 802.1X status changes on a port. This isn’t always the case though. I haven’t tested all supplicants yet but certainly some of them (Mac’s built-in supplicant for example) don’t do this. This leaves you with a sequence like this:
This is an example of the nascent nature of 802.1X supplicants in general. I can’t think of a valid reason why you wouldn’t do a release renew yet some still don’t. This has been a known issue for quite some time now. In fact I describe a more pernicious variation of this issue in my book:
During my testing, I found a lack of integration between the 802.1x client and the DHCP client in Microsoft Windows 2000 … By the time authentication by 802.1x occurred, the PC had already timed out its DHCP request and opted instead for a link local address (169.254.0.0/16). Though the user could manually go in and restart the DHCP process, for most users this will be infuriating. (343)
There is a reasonable workaround here though it isn’t quite ideal. When the user is placed on a default VLAN–as described in my earlier post–they can be sent through a captive portal device. This captive portal generally provides local DHCP services for the default VLAN as well. So one approach is to simply set the DHCP lease time quite short for these guest systems. Something between one and two minutes is probably appropriate. So now if you start up your 802.1X supplicant after being temporarily placed on the default VLAN, you will only have a short time to wait before the DHCP client gets the proper address.
If you wanted to get really slick you might increase the time of the lease based on the number of times it has been renewed–each renew increases your confidence that the host is actually a guest user. That may add more complexity than it is worth plus it isn’t like the DHCP process is particularly compute intensive, especially if the short lease only applies to guest users. (As an aside, I’m no DHCP expert so I’m not certain if this lease scaling can even be done.)
Regardless of the DHCP particulars this approach will provide a safety net for less than optimal supplicants when working in a network that implements the default VLAN. If you’ve had experience working with this in the field, I’d love to hear about how it went. We’re using this technique in the office here for guest users and according to IT and the guests I’ve talked with it works fairly well.
Technorati Tags: 802.1X, Supplicant, DHCP, VLAN
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.
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.
You are currently browsing the archives for the 802.1X category.