Having a free minute on my hands, I decided to go back through some of my older posts and assign some tags. Innocent enough. The only problem is that the Twitter plugin I use here at Tuesdaynight treats those edits as new posts, adding them to my stream of tweets. Sorry ’bout that, those of you following me at Twitter.
I really like the current capabilities and promise of NAC. I do, however, have a problem with the abbreviation, specifically, the “A” in NAC. Which do people mean when they say NAC: “network admission control” or “network access control”? To me, there are big differences between the two.
NAC as Network Access Control
If you have an identity background, when you hear NAC, you think, “Oh, this is web access control for the network.” If that’s the case, then NAC needs to have some features that mirror WAC. For example:
• Identifying the user is key.
• There needs to be a centralized policy store that describes access control.
• There needs to be a fine level of granularity of those policies.
• There needs to be some modicum of single sign-on.
• There’s going to be some form of the proxy versus plug-in fight.
User authentication has always been a part of web access control, and network access control should be no different. WAC vendors have all sorts of mechanisms to authenticate the user either directly or through other authentication providers. NAC vendors do, but, I conjecture, not in the same way. There are two flavors here: explicit and implicit. Explicit NAC authentication involves the end-user in an authentication event. Forcing the user to authenticate to RADIUS is a form of this. Implicit authentication uses authenticated credentials from something higher in the stack (like the operating system) and not involving the end-user in an extra authentication event.
Centralized policy store — yes, they exist. The market has no problem building policy stores. In fact, as I have mentioned before, there are too many policy stores out there today, with little integration and hierarchy to them. Can I use a single policy tool for all of my identity-based access control? Nope, not yet. I have heard from numerous people: “I already use vendor X’s web access control tool. Can I use it to describe policies for network access control?” The funny thing is this existed nearly 10 years ago. DASCOM’s IntraVerse had both a web component (WebSeal, part of IBM Tivoli’s Access Manager for e-business) and a network component (NetSeal, which lived about as long as a drummer for Spinal Tap.) What’s old is what’s new, and I guarantee that in the next couple of years we’ll see a return of this model for a variety of reasons.
Fine-grained policies — can I describe a network access policy down to the object level: file, row, transaction, etc.? Kinda, sorta, maybe. There are vendors that do this, but they are typically application specific. There is a gap between that level of control that various products provide and more general network access control. Part of the issue is that getting a NAC product deep enough into an application to get that level of granularity isn’t easy and requires modifying and/or distrupting the application. Further, as anyone who has ever tried to maintain group permission information knows, the more objects you want to tie to group permissions the harder it gets to work with. (This is why user-provisioning tools have shied away from group management at any deep level.)
WAC products had basic single sign-on, at least for the applications they protected. If NAC is really an offshoot of WAC, you’d expect the same. Does this mean that Imprivata and Passlogix and the like are NAC vendors? I think that’s a bit of a stretch. Will NAC vendors grow PAM modules? Someday, but not any time soon.
Back in the day Netegrity and IBM fought it out over the best architecture for web access control. Was it better to deploy proxy servers to control access or plug-ins to application servers? At the end of the day, the answer was: it depends. Both vendors supported both. Will this architecture difference arise in NAC-land? I wouldn’t be surprised if it did. We already see SSL VPN vendors acting as a form of proxy server. Could we see a rise in plug-ins to applications running on the network to provide extended NAC services? Maybe, but I think we’ll see SPMLv2 adoption before we see NAC plug-ins for applications… either way — don’t hold your breath.
After the 4th, I’ll be back to examine the other “A” in NAC – admission.