Sean Convery

James McGovern’s blog recently made mention of Identity Engines, the company I work for. The mention was in the context of when appliances made sense for identity. I thought I might take a moment to explain a bit more about what our product does and then perhaps we can have more dialogue about the suitability of appliances. The current product we make is a 1RU appliance focused on the network identity space. The product ties together back-end directories with the network access devices that provide connectivity (This primarily means linking wired, wireless, and VPN access points with directories like LDAP and Microsoft AD.) Once tied together, we enable rich policy decisions to be made around what sort of network access a user should be granted and under what conditions. This is contrasted with the application identity management market which not a space we’re playing directly in today.

We chose an appliance form factor primarily for ease of use by the network operators which typically deploy our product. These individuals generally have little interest or time to install and maintain an OS on a server and additionally the application which runs on it. Running on an appliance also lets us do some basic things to protect the information contained within, such as hardening the OS and using an encrypting file system. In the network security world you generally see the delivery vehicle of a particular security technology evolve over time. First it is found in software on a general purpose OS, then it is found in an appliance, and finally it is available integrated into the network infrastructure (running on routers and switches). This evolution has happened several times now in the industry (firewalls, VPNs, IDS/IPS). What drives the transition from one platform to another has a lot to do with the maturity of the technology and the market.

(As an aside, I completely agree with James’ comment about the potential usefulness of XACML. Policy portability could have all sorts of benefits in the near future.)

This week my company and hundreds of others descended upon the McEnery convention center in San Jose for the annual RSA show. We had great traffic and managed to have scores of conversations with potential customers and partners. While the fact that I am in this space should serve to temper my enthusiasm, the show was all about identity and controlling it at the network edge. There were many new startups as well as established players talking about security enforcement in the campus through user authentication and endpoint posture checking. This only serves to solidify my thoughts around the emerging role that network identity management will play in the coming years. Writing policies within each of these enforcement devices does not scale long term and will lead to compliance challenges, not to mention excessive opex costs. Centralized user and device policy seems like a much more scalable way to go long term given the desire for consistent user access rights paired with the heterogeneous reality of today’s networks.

Over the holidays I read an interesting article on a proposed complete redesign of the Internet. The work is in its nascent stages within the NSF and has a vocal supporter in David Clark at MIT. This design effort could take five to seven years at a cost of $200 - $300 million. It is often interesting to undertake green-field design efforts to see what sort of an ideal could be realized and what things you are giving up by only changing the current architecture in incremental ways. The focus of such an architecture will–big surprise–have a lot to do with security–with many of the security improvements in the area of authenticating users and devices.

This identity problem is something authenticated networks can try to address. Technologies like VPNs and 802.1x can improve overall security by authenticating the user associated with a particular machine. This can tell us, for instance, that 192.0.2.52 is currently Sam in finance. This is extraordinarily useful in enforcing network policy. As I’ve outlined in prior posts, users no longer are fixed to a given IP address making filtering based on IP address in a firewall quite difficult. This is because the IP address has lost much of its context over the years.

One of the problems with authenticated networks–which could benefit from more exploration–is the coupling of user authentication with the IP address. Today, even with VPNs and 802.1x, all the good authentication work done at the edge is lost once the packet is sent into the rest of the campus network. For example, we determined that 192.0.2.52 is Sam in finance but how does the next policy enforcement point learn that? Certainly not through any identifying information in the IP packet. This means any filtering you wish to employ for the user requires enforcement at the same point you apply the user authentication. This is far better than nothing but certainly not ideal since it requires describing all possible destinations for a given user in order to keep with the network security principle of “expressly permit, implicitly deny.”

Technologies like IPsec can help but have not yet seen widespread adoption for a variety of reasons including complexity issues around configuration, interoperability, and key management. Some promising experimental work in the IETF is the Host Identity Protocol working group. They have defined an architecture around host identity which may have extensibility into the user space. I’m just starting to explore this and hope to spend some time with some of the principals at the next IETF in Dallas.