Got the NAC
SteveHanna

What do you need to know?

by Juniper Employee ‎10-03-2008 03:22 PM - edited ‎10-03-2008 03:26 PM

The IETF’s NEA Working Group is (among other things) standardizing a set of “PA-TNC attributes” for use during NAC health checks. These standard attributes will  be implemented in many network endpoints (laptops, desktops, printers, etc.) so that a NAC server can query an endpoint and obtain information about its health in a standard way. The tricky part is deciding which attributes are important enough to be in the first standard and which attributes can be left to future standards or vendor extensions.

 

I bet you have some ideas on this topic. Review the current draft list of attributes (below) and post your comments. I’ll bring them back to the NEA WG. Thanks!




A standard set of components are defined and then a standard set of attributes that describe aspects of those components. This avoids the need to define separate attributes for “OS Version”, “AV Version”, etc. Of course, some devices won’t implement all these components and attributes. No Anti-Virus on my printer (yet!).

Components: Operating system, Anti-Virus, Anti-Spyware, Anti-Malware, Host Firewall, Host Intrusion Detection and/or Prevention System, Host VPN

Attributes: Product Information (vendor, name),  Numeric Version, String Version, Operational Status (operational?, problems detected?, last time run), Port Filter List (for Host Firewall), Installed Packages (name, version)

Message Edited by SteveHanna on 10-03-2008 06:26 PM

SteveHanna

What about IF-PEP?

by Juniper Employee on ‎09-05-2008 12:08 PM


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 ideal.

 

Thanks!

 

 

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.

SteveHanna

IETF NEA

by Juniper Employee on ‎09-05-2008 12:02 PM

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 out.

 

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!

About Got the NAC

Steve Hanna
Welcome to Got the NAC, written by Juniper Networks Distinguished Engineer Steve Hanna. From his insider perspective, Steve blogs about network access control, covering the issues and trends he encounters that affect the industry as a whole.

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)
Labels
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.