I’m in NYC for Interop NY today. I’ll be speaking on a panel about NAC at 10:15 AM with Microsoft, Cisco, and Nokia reps and Mike Fratto as moderator. It should be entertaining and enlightening. At least, I hope it will be! I’ll blog about it this afternoon. If you’re at the show, please come by and say “Hi” or ask a question.
I wanted to point out Mike Fratto’s blog posting about the NAC Day panel. It sounds like a great discussion with customers pushing hard for vendors to support NAC standards. The TNC standards have been out for more than three years now and free for anyone to implement. Most vendors have done so or at least announced plans to do so. Cisco is the only holdout. I’m glad to see customers pushing hard for them to support these standards. I hope these words translate into actions. As they say, “money talks”! The only way to get some vendors’ attention is to put a requirement in your NAC RFP saying “must support the TNC standards”.
Last week, I was at the RSA Conference in San Francisco, a global gathering for information security folks. This event has already been covered by hundreds of bloggers and journalists so I won’t cover the basics. However, I do think it’s useful to highlight a few NAC-related events.
First, I was glad to see that NAC vendors are converging on IF-TNCCS-SOH as a standard client-server protocol. This addresses several concerns that customers have had about NAC: complexity, compatibility, and cost. Now that everyone is agreeing on one client-server NAC protocol, customers won’t have to worry about whether their NAC system is compatible with their PCs, their non-PC devices, and their contractors’ and customers’ devices. Support for the TNC protocols will just be built into the client operating system. This will reduce complexity and therefore cost by eliminating the need to install a special NAC agent on the device. Of course, the nirvana of universal NAC support is not here yet. Macs, older PCs, and many other devices don’t yet come with NAC support built-in. But the trajectory is clear. In a few years, NAC support will be as ubiquitous as DHCP is now.
Second, I participated in a panel session with Cisco and Microsoft on NAC. This is the third year we have done this panel at RSA. The first year, there was blood everywhere. The second year was a bit more restrained. And this year, I’m happy to say that everyone agreed on the value of the TNC standards. Even Cisco is on board, now that IETF has pick up the TNC specs. I still don’t agree with Cisco about everything. We had a few tiffs on the panel. But we agree on the need for NAC standards and the fact that the TNC standards are those standards. That’s the essential bit.
Finally, NSA (the U.S. National Security Agency) was demonstrating the High Assurance Platform, a multi-level secure workstation built on the TNC and TPM standards. This is really important. For one thing, it shows how open standards are being used to build super-secure systems out of inexpensive, commercial parts. For another, it will provide a big benefit to U.S. warfighters. Today, they must carry three laptops: one for secret materials, a second for top secret, and a third for unclassified. With HAP, a single laptop with a secure hypervisor (based on VMware) runs separate VMs for the separate classifications. This will literally lighten soldiers’ load, allowing them to be more agile or carry more arms and armor. Commercial road warriors and infosec teams may not carry guns but we are at war with cyber criminals. If TNC and TPM are strong enough for the NSA, they must be strong enough for your organization.
I’m happy to say that the IETF NEA Working Group has decided to adopt several of the latest TNC standards as Working Group drafts! Let me answer some frequently asked questions about the process and the drafts. If you have more questions, please post them and I will try to answer them.
Q. Does this mean that these TNC standards are now IETF RFCs?
A. No, there’s still a long path to follow before they can be published as RFCs (the IETF’s term for their officially published documents). But it does mean that the NEA WG is working to develop RFCs based on them.
Q. Where can I get a copy of these specs?
A. In the cryptic manner of standards groups, there are two versions of each spec: the IETF version and the TCG version. The IETF specs are PA-TNC and PB-TNC. The TCG specs are IF-M 1.0 and IF-TNCCS 2.0. The only difference is the formatting and terminology!
Q. What if the NEA WG wants to change these specs before they become RFCs?
A. That’s OK. Everyone expects that. All standards go through changes and revisions, like HTTP 1.0 and 1.1. The protocols and products are designed to support such changes with a smooth and gradual transition. It’s worth it to get everyone on board.
Q. I have another question!
A. Ask it below in a comment and I’ll answer it.
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.
Steve Hanna is co-chair of both the Trusted Network Connect Work Group in the Trusted Computing Group and the Network Endpoint Assessment Working Group in the Internet Engineering Task Force.
Steve is active in other networking and security standards groups, such as the Open Group and OASIS. He's also the author of several IETF RFCs and published papers, an inventor or co-inventor on 30 issued U.S. patents, and a regular speaker at industry events such as Interop and the RSA Conference.
He holds an A.B. in Computer Science from Harvard University. For more information on Steve, check out Network World’s profile (by Tim Greene)
- JNetTawnee on: Decrypting RSA Europe
- on: Today’s NAC Panel at Interop NY
- on: New Audio Podcast on my Trip to India
- Biilo on: Summertime…
- Ken Y-N on: New Video Podcast Posted
- Tarek Amr on: IF-MAP: Integrating All Network Security
- Tarek Amr on: IETF Picks Up TNC Standards
- on: IETF NEA
- Steve Hanna (SteveHanna) on: Trusted Network Connect (TNC)
- on: Enforcement Options