I’m sure you’ve been perched on the edge of your seat, waiting to
see what would happen in the next episode of the riveting drama of NAC
standards. In our last episode, the IETF NEA Working Group had issued a
call for client-server NAC protocols to be considered for
standardization. Who would answer this call? We were all waiting to see…
February 18 was the deadline for submitting proposals. That evening,
I logged in from my vacation in the Florida Keys and found… one proposal from the Trusted Computing Group (TCG). The TCG proposed a slightly modified version of the IF-TNCCS and IF-M protocols that are part of the TNC architecture.
After seeing this, I breathed a sigh of relief. I had been worried
that we might end up with competing NAC standards (like HD DVD and
Blu-Ray), resulting in confusion and delay. We seem to have dodged that
bullet. Since the only proposal was the TCG proposal and the TCG
indicated that it is willing to work with the IETF to resolve any
problems and arrive at a single common standard, all signs point to the
development of a single unified standard supported by TCG and IETF.
Maybe Cisco will even support the standard, since they were the only
major vendor holding back from supporting the TNC standards.
A bit of disclosure is probably in order here. I am co-chair of both
the TCG TNC Work Group and the IETF NEA Working Group and also a
co-editor on one of the TCG proposals to the IETF. Wouldn’t you think
that would put me in the know and keep me from worrying about the
outcome? Nope. I spent February 18 worrying, like Bill Belichick of the
Patriots on Super Bowl Sunday! Would someone else make a proposal? Who?
Even now, nothing is completely certain. Standards are a complicated
and delicate process of building consensus. It looks like we’re headed
toward consensus on these specifications but it won’t be completely
certainly until years later.
The first stop on our guided tour of NAC standards is Trusted Network Connect (TNC). TNC is a complete set of standards for NAC, covering each step in the NAC process, from assessment to evaluation and enforcement. Like all good standards, TNC is completely vendor-neutral and open for anyone to implement.
What does this mean concretely? When you buy products that support the TNC standards, you can use a NAC server from one vendor with an enforcement device from another vendor. A NAC client from one vendor can be health checked by a NAC server from another vendor. And you can add assessment and evaluation components from other vendors, plugging those into the NAC client and NAC server.
Sure, that’s cool. But what are the specific customer benefits? First, you avoid vendor lock-in. Proprietary NAC architectures are designed to lock you into one vendor’s products. That way lies madness: single-vendor contracts, high prices, etc. Second, with the TNC standards you can reuse the technology you already have: switches, wireless access points, client security software, etc. There’s no better way to improve ROI than to reuse something you already bought! Finally, you get better security. Open standards go through a rigorous review process that has given us the strongest security available today: AES, TLS, IPsec, etc.
How did TNC come to be? It was developed by the Trusted Computing Group, a consortium of about 175 vendors and customers. The TNC standards were published in 2005 and 2006. Since that time, dozens of products that support the TNC standards have shipped. Hundreds of customers have deployed them. TNC adoption is accelerating, especially since Microsoft announced that TNC support is included in Windows Vista and will be included in Windows XP Service Pack 3. The TNC standards have become the de facto standard for NAC interoperability.
Want to learn more? Check out the presentations, podcasts, and specifications on the TNC web site.