Sean Convery

Yesterday I presented at the Secure IT Conference in Sacramento, CA. I did a presentation on identity management applied to networking called “RADIUS Grows Up: Identity Management for Networks.” If you are new to the space, this presentation should give you some good background on what problems need to be solved, and what some possible approaches are. In other news, my cast is off and the arm splint should be gone next week!

Technorati Tags: NAC, Identity Management

One of the more exciting aspects of authenticated networks is that once you do it, role-based access control becomes possible. Today–as I’ve said before–authentication for wireless, VPN, and dial-up connections has the principle goal of proving that you should be treated like you were in the building. Wired access typically has no authentication. However, if you authenticate your wired access as well, now every access method is authenticated and the game changes. With the user’s identity validated at every point of access, now we can ask what the user should be allowed to do.

At this point vendors and customers can get overly excited and start talking about dozens of roles based on the different areas of the organization. The problem is many larger organizations have no idea what specific authorizations each role needs. Instead of jumping to the end game, organizations should instead look to a smaller number of roles. A good place to start is simply to differentiate between a guest, a contractor, and a permanent user. Guests typically need access only to the Internet. Contractor’s needs vary widely but generally need access to a subset of internal resources. Locking down contractors will still require some homework for a network IT staff but it is a far more tractable problem than figuring out all employee entitlements. Lastly the permanent user role gets access to everything, as normal.

From these meager beginnings, you can begin to extend your role-based access control. The next logical step for many organizations is a “privileged” role which could be granted to finance, HR, and executive staff which grants access to the servers which house very sensitive data. It is important to remember that even with just three roles though, you’ve significantly extended the functionality the network provides over what it did before authenticated networks.

Technorati Tags: 802.1X, NAC

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

Back in June I wrote about a new draft in the IETF RADEXT working group concerning access control lists (ACLs). The draft specified a way to generically format and transmit IP ACLs using RADIUS. The draft is now in its sixth revision and left the working group headed towards a proposed standard in the IETF. If approved, we will finally have a common technique for passing ACLs to a network enforcement device from a AAA server. The approach taken in this draft is to reuse the filter format defined within Diameter (scroll down to page 44 to see the format). To date, enforcement vendors have either relied on proprietary techniques for formatting these ACLs or have simply not supported them. It is very common today to see no support for the specific ACL but a more general support for the RADIUS Filter-Id attribute (attribute 11, page 35). The Filter-Id attribute is nice but it only allows the AAA server to point to a pre-existing filter on the enforcement device, not to create one on the AAA server.

The key, if approved, will be getting the enforcement vendors to support the new standard. Since HP authored the draft It seems quite likely that HP will support the capability. If Cisco and Juniper follow suit it would be great news for customers struggling with network level authorizations throughout a heterogeneous network. My guess is customer pressure will be instrumental in getting the big guys on board. Pairing this functionality with network-wide authentication and some basic NAC checks and you’ve suddenly got a heterogeneous solution which hangs together quite nicely. Heck, toss in RFC 3576 support and you’ll really be onto something.

Technorati Tags: 802.1X, NAC, RADIUS

Apologies for the TCP humor.

An interesting article at Network World points to an analyst report from TheInfoPro about NAC. The report, due out next month, shows that “of 126 network professionals, 37% say it is very likely or extremely likely they will decide to develop or implement a NAC policy initiative in the next 12 months, down 17% from earlier this year.” Reasons cited include a lack of standards, high cost, and the lack of a universal endpoint agent.

I always had a sense that NAC–as narrowly defined under the endpoint health banner–might find the “trough of disillusionment” (as Gartner describes it) earlier than expected. With so much hype, so little standards, and so many vendors piling on with solutions it seems almost inevitable. Much of my talks with customers, at conferences, and in posts on this blog have encouraged caution in approaching this problem space so quickly–and so narrowly focused on endpoint health.

Making user identity decisions at the time of network access is a much more proven technology since it has been used to augment the security of dial-up, VPN, and wireless networks at scale. Adding wired access to the authentication solution makes it possible to make access decisions for all forms of network access in a consistent way. Sure wired 802.1X is encountering its own growing pains, but vendors have responded by enabling simpler alternate mechanisms–such as web authentication–to bootstrap wired deployments until 802.1X is truly plug-and-play. It will be interesting to see how this plays out over time.

Technorati Tags: NAC

If you’ve been watching the NEA mailing list lately, you’ve probably seen a rather long thread discussing privacy concerns with NAC technology. While the thread had the usual IETF silliness–and I was unable to resist throwing my own thoughts in as well–it does raise some important points.

With NAC and a single policy domain you have no issues; both the network operator and the client machines themselves are owned by the same entity. So as an example, if FedEx wants to scan a FedEx asset before it connects to the FedEx network, we have no issues. Where the problem comes in is if the network and the machine are owned by different entities. This is common with contractors, vendors, and guests that have their own client machines but are connecting to a network which is controlled by another entity. With contractors this isn’t as big of an issue but for an unaffiliated guest (such as someone attending a training class) it is.

For an extreme example of this, imagine a FedEx machine connecting to the UPS network as a guest: perhaps FedEx is hosting some shipping-industry user-group onsite. The FedEx machine has sensitive FedEx data and configuration information and is controlled by policies defined by FedEx. When it connects to the NAC-enabled UPS network the FedEx machine will be asked to provide client security information to the UPS network. This client security information could include OS patch levels, AV signature levels, registry settings, or the presence or absence of specific data or applications. While this information is being used, in theory, for noble purposes (to evaluate the risk in letting the FedEx asset connect) the check itself is providing the same sort of information that a piece of spyware code might.

Since there are no widely deployed and standards-based NAC solutions, some organizations have deployed NAC interrogation software which relies on downloading a Java or ActiveX applet to the client machine which runs the scan. This could quite understandably violate the security policy of the client machine’s owner. Likewise, without the scan, the network operator’s own security policy may be violated because there is no visibility into the risk level of the connecting asset.

There are two elements in the solution to this problem. First is some ability for the client machine to understand what it is being asked to provide, and who it is being asked to provide it to. This could be done through authorizations in the OS configuration itself or through providing a pop-up to the user informing them that the network the are connecting to is requesting certain information. The key to this disclosure is that it be made by the client machine itself and not some downloadable applet which may not be trusted by the client machine’s owner.

This leads directly to the second element: standards. In order to facilitate this disclosure we need standards for how information is requested and authorized to be sent. NEA can hopefully help here and requirements around these disclosure authorizations are already being explored on the NEA mailing list.

In the meantime, I expect users to comply unknowingly to detailed scans of their systems and that those performing these scans will have good intentions. I don’t see it as unrealistic, though, to expect that malicious forms of this interrogation will be seen in the future. Another short-term option is to not perform client checks on guest systems at all but rather segment them to a partitioned VLAN within the network which runs their traffic through some sort of inline IPS solution. You could still check the guest’s identity at point of connect to enable the segmentation. Then the guest could establish a VPN link to their home network for confidentiality while remote.

Technorati Tags: NAC, privacy

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

After a fair amount of debate, Network Endpoint Assessment (NEA) is now an official working group in the IETF. The group is initially chartered with only defining the requirements though. From Russ Housley’s email announcing the group:

Second, only the milestones related to the requirements document are approved. The idea is to get going with the architecture, requirements, and security analysis. These are all included in one document. The other milestones will be approved by me (not a re-charter action) once the IETF Last Call demonstrates that the NEA WG is moving in an direction that the community can support.

The timeframe for final requirements is April of 2007 at which point the other milestones may be approved. There seems to be some hesitancy in the IETF around this topic hence the staggered milestone approach.

Technorati Tags: NAC

Building on the identity-centric NAC talks at Digital ID World, there’s been more buzz about why identity needs to play a significant role in NAC. Andrew Braunberg at Current Analysis has an article up on the topic which makes a sound case for expanding the definition of NAC.

The benefit of user identity awareness within NAC solutions is really a no-brainer. It’s interesting that NAC solutions are so commonly positioned as security solutions because they are only tangentially about security. As originally envisioned, NAC did not provide any additional security functionality, but rather it ensured that organizations were fully leveraging their existing security investments (e.g., check that the antivirus software is installed, turned on, and updated).

Full disclosure, he also has a nice plug for my company’s partnership with Oracle in there somewhere.

Technorati Tags: Digital ID World, NAC