IETF Strives for NEA Standard

Vendors have put their bobbers in the water trying to catch enterprise fish with the idea of network endpoint assessment. But though various NEA architectures improve endpoint security, they also lock enterprises into proprietary security architectures. The IETF aims to solve this problem with a specification that will let any endpoint software talk to any authentication-enforcement architecture.

For the industry and customers, the IETF's NEA efforts are important. Cisco Systems and Microsoft have proprietary technologies--respectively, Network Admission Control and Network Access Protection--that may lock the market into one or the other. The NEA standard represents a neutral market option that will let more players have a fighting change. The framework focuses on standardizing some of the underlying protocols--including the PB (Posture Broker) Protocol, the PA (Posture Attribute) Protocol, and the PT (Posture Transport) Protocol. Other parts of the communications process and protocols used to communicate between different parts of the NEA server won't be defined by the working group at this time because they are less important to end customers.

NETWORK ACCESS CONTROL
Immersion Center

NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE

The real question is how well the IETF's efforts will pay off. Juniper Networks' Stephen Hanna and Cisco's Susan Thomson chair the IETF's NEA Working Group, which indicates the effort is being taken seriously in the industry. (Hanna is also co-chair of the Trusted Computing Group's Trusted Network Connect, which has a stake in the NEA game.) However, participation doesn't always equal adoption. The customer benefits of standardizing the PA and PB protocols are clear. For the vendors, the motive is the possibility of increased adoption by the enterprise. That being said, the real magic and money for vendors in NEA is on the back-end systems, rather than in the desktop agent.

Continue Reading This Story...

Use Cases

Companies such as Cisco and Microsoft have been talking about and working on interoperability for their setups, but those talks leave initiatives such as TNC out in the cold. The goal of the IETF is to provide endpoint compatibility among all NEA products. For customers, this will let them perform an endpoint assessment on visitors' machines regardless of the NEA client they use. An NEA standard also would be useful when companies are acquired; if the company being acquired uses an NEA product different from that of the new parent company, converting the acquired company's machines to the preferred system would be much simpler. Another less likely example would be if a company prefers one vendor's endpoint and another vendor's back-end NEA solution, the IETF's NEA efforts would let them work together.

Some of the functions of the PA, PB and PT protocols overlap to accommodate the myriad and varied use cases for NEA in general. While this may seem unnecessarily complex, a good standard must take into account all possible uses, and this complicates the standard somewhat.The PA Protocol is designed to carry messages between a Posture Collector (on the client) and the Posture Validator (on the NEA server; see "NEA Model," at right). It handles the specific attributes that result in a full posture. This protocol also provides security for the attributes in the form of encoding and encryption. The characteristics of these attributes will be set by the NEA working group and should be part of any end-station client that complies with the standard. There also may be vendor-specific attributes that are not yet defined by the NEA working group.

The PB Protocol carries attribute messages, aggregated from the same client, between Posture Collectors (on the client) and Posture Validators (on the server). It starts a session that allows for the exchange of multiple messages. It also can bind multiple requests/responses from different Posture Collectors and Posture Validators involved in the assessment of a single endpoint. This is important, especially if there are several validators for different tasks, such as one for antivirus and another for OS patch state. The PB Protocol also can carry resulting decisions to the Posture Broker Client.

The PT Protocol carries messages generated by the PB Protocol between the NEA client and NEA server. These messages must be delivered reliably, and the communications should be secured with two-way authentication and encryption. The PT Protocol in turn will be carried by lower-level protocols, such as RADIUS, 802.1X, IKE or TLS. The PT Protocol won't be able to view the PB messages it contains and will operate regardless of the content of those messages.

Arrival In The EnterpriseFor the most part, enterprise customers won't have to worry about the specifics of how these IETF protocols are implemented. However, enterprise IT departments must keep an eye on the efforts and communicate with vendors as to whether their products will conform to the NEA specs. Even if your organization doesn't have any plans to make use of this kind of interoperability when it comes to fruition, there may be acquisitions or other reasons why it might be an important consideration in the future.

The IETF has asked for an Internet Draft to be submitted by December 2007. This may seem slow to some, but it takes time to bring all the interested parties into agreement. This effort is a worthy one that will benefit enterprise customers and, in the long run, vendors in increased adoption of the technology.

Steven J. Schuchart, Jr., a former NWC technology editor, is an analyst for competitive intelligence firm Current Analysis. Write to him at [email protected].