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
In a comment on my last post, Grant Hartline wrote:
I’m happy to see the movement towards unification of
standards and appreciate all of the effort you’ve put into NAC
standards adoption, both within the TCG and the IETF. However, one TNC
standard that is conspicuous in its absence is IF-PEP. Is there an IETF
working group that may pull in IF-PEP for the purposes of triggering
enforcement actions? Alternatively, or at least in the meantime, do you
see any movement within what we’ll call “the industry” on adoption of
RFC 3576 within Ethernet switches?
Let me answer some of Grant’s questions here. First, bit of
background. IF-PEP is the TNC’s standard way for a Policy Decision
Point (PDP) to send instructions to a Policy Enforcement Point (PEP).
Those instructions might be “put this user on a quarantine VLAN”, for
example. The TNC standard for IF-PEP is currently IF-PEP for RADIUS 1.1.
To answer Grant’s first question, there is in fact an IETF WG that
works on this protocol. It’s the RADEXT (RADIUS Extensions) Working
Group. If you look at IF-PEP for RADIUS, you’ll see that it cites a
bunch of IETF RFCs. In fact, most of the TCG spec is just “use IETF RFC
3580 in this way” and things like that. So the IETF is already on board
with IF-PEP for RADIUS. That’s one reason why TNC is so compatible with
existing networking gear. RADIUS has been around for more than ten
years. All enterprise grade switches and wireless access points support
it, also many VPN gateways and things like that. There was no reason
for TNC to reinvent the wheel. Reusing the existing IETF protocols
provided maximum compatibility.
Grant’s second question is whether there’s any movement on adoption
of RFC 3576 in Ethernet switches. For those who aren’t totally up on
their RFC numbers, RFC 3576 describes
how a PDP can send real-time updates to previous enforcement
instructions to a PEP. For example, “please move that user out of the
quarantine VLAN onto the production VLAN”.
RFC 3576 is about five years old and it has not been widely
implemented by switch vendors to date. This is a shame because it makes
it hard for a PDP to move users around as conditions change (change in
user privileges or endpoint health, change in policy, etc.). The usual
ways to handle this are to use another way to send the updates (SNMP or
CLI), have the PDP ask the endpoint to request reauthentication from
the switch, or configure the switches with a short reauthentication
timeout. None of these are ideal. The first is proprietary and
unreliable. The second depends on the endpoint to behave nicely. And
the third is inefficient. Implementing RFC 3576 (also known as CoA for
Change of Authorization) is clearly the way to go.
I have heard that a lot of switch vendors are moving now to
implement RFC 3576. I want to provide a more complete answer for Grant
so I’m going to do some research on this. I’ll submit another blog
posting in a week or so with more information. If anyone has info on
this topic, please post it as a comment. Links to data sheets would be
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
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.
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 TNC specs are good but some people prefer a more formal approach to standards. For example, Cisco has said
that they prefer to work on NAC standards in the Internet Engineering
Task Force (IETF). Getting Cisco and others to agree on NAC standards
is important, so the IETF has formed the Network Endpoint Assessment (NEA) Working Group
to work on standard NAC protocols. I co-chair this NEA Working Group
with Susan Thomson of Cisco and lots of other folks from the network
security industry are involved so this is a good forum to hammer things
The NEA Working Group (pronounced “nee-ah” by those in the group) recently approved a NEA requirements document.
Now the Working Group is soliciting proposed protocols that meet those
requirements. The proposals are due by February 18, 2008. It will
certainly be interesting to see who submits proposals and what happens
with them. Will Cisco submit a proposal? TCG? Someone else? Tune into
my blog on February 19 and I’ll give you the answers!
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.
NAC is inherently a multi-vendor problem. Assessment needs to work with all the different endpoints connected to your network: PCs, Macs, printers, phones, security cameras, etc. Evaluation needs to know what’s normal for each of those kinds of endpoints. And enforcement needs to work with whatever enforcement mechanism you want to use, preferably leveraging the network equipment you already have in place.
Because of NAC’s multi-vendor nature, everyone now agrees that we need NAC standards. Every endpoint should implement a standard NAC protocol so that its health can be checked as necessary, in accordance with local policies and regulations.
However, the world of NAC standards is complex and evolving. In my next few posts, I’ll give you a guided tour of the world of NAC standards.
How do I know so much about this? NAC standards is my job. I work on this full time. I’m co-chair of both the NAC standards committees: TCG TNC and IETF NEA. So I know what’s up in this area and I’m glad to explain it.