Sean Convery

With the announcement of OpenSEA and some new announcements from my company, I’ve been away from blogging for a while. Plenty has happened while I was gone. First, Microsoft and the TNC announced that a core NAP protocol would be part of the TNC. Second, OpenSEA got great press and we’re seeing lots of interest from new companies in joining. Finally, Caymas Systems went under making at least one of my blog predictions for 2007 correct. Each of these probably warrants its own post and I hope to get to each soon.

Technorati Tags: 802.1X, NAC, OpenSEA

Today I am thrilled that the formation of the OpenSEA Alliance has gone public. We’ve already had some nice press coverage. OpenSEA (Open Secure Edge Access) formed to promote the development of an enterprise-grade 802.1X supplicant. We’re basing our work on the existing XSupplicant. The founding companies are Extreme Networks, Identity Engines, Infoblox, Symantec Corporation, TippingPoint, Trapeze Networks and UKERNA. Jon Oltsik and I blogged about this a while back and this is the result of Jon’s efforts to corral the right industry players to make this happen. I’ll follow up with another post once I’ve had a chance to digest the industry reaction. For now, the FAQ has lots more information.

Technorati Tags: 802.1X, AAA, NAC, Supplicant

While normally I would shy away from mentioning Identity Engines’ online events here, I’ll make an exception this time. I’m presenting the IdM-N talk on May 10th at 11:00 AM PDT via the web. If you’d like to hear me talk through some of the concepts live and ask questions (though you’ve always got the comments field on this blog) feel free to register. I can’t guarantee one of our friendly sales guys won’t call you, so consider yourself warned. I’ve got a few slides at the end on what Identity Engines does but the bulk of the talk is vendor neutral. The talk will be nearly identical to what I delivered to Secure IT, NYMISSA, and the NAC so if you are familiar with the material in those presentations you can safely skip this one.

Technorati Tags: AAA, Identity Management

Eric Norlin responded to my Identity Management for Networks post with some thoughts of his own. It sounds like we are mostly on the same page (i.e. he agrees sticking the “N” or “A” at the end might help) however he did point out some real challenges to the merger of the two spaces:

Sean sees identity management becoming a “single entity.” I’m not as optimistic. There’s an awful lot of legacy to get through here — legacy of job titles, legacy of how software and networking companies are organized, just plain legacy. Will IdM-N and IdM-A products and suites have to learn how to be intertwined? Absolutely. Will they merge? That sounds like a ten year job to me.

I actually think we agree here more than we disagree. I absolutely agree that this will take a while, perhaps not 10 years, but certainly more than a couple. Eric’s post and my conversations at the recent NAC conference got me thinking about the phases of integration. This certainly isn’t a binary switch-over and I doubt we’ll want to get to one solution from a vendor that addresses all your identity needs. Hopefully Eric will chime in here as I’m guessing I’m missing some steps, but these are the big stages of integration that jump to mind.

1. Networks and applications use the same back end directory for user authentication. I think we’re mostly here now, or very close to it. Whether it be through a meta / virtual directory or direct to an AD or LDAP store, the customers that I’m engaged with either are already using a single directory infrastructure or are rapidly moving toward it. Of course bridging across multiple directories, groups, and attributes will remain critical, but this will be pain experienced equally by the applications and the network.
2. Networks and applications trigger authorization policy based on the same groups and attributes. This isn’t yet happening consistently within applications so it certainly isn’t happening consistently between networks and applications. Getting this to happen has a lot to do with step three, below.
3. HR user provisioning systems create one user record which automatically has associated application and networking rights. This is another place where we have work to do. Today an HR provisioning system from one large vendor might only deal with rights and authorizations for that large vendor’s applications and not the rest of the infrastructure’s needs. However, creating the right workflow so that, say, the HR system can define a user as an employee, privileged employee, or contractor would allow the network to inherit those authorizations and enforce them within the network context.
4. Network and application policy decision points (PDPs) share policies or audit information. This is another area that needs lots of work. Standards like XACML make this easier, but there still needs to be a defined schema for the attributes and an understanding of why the policies would be shared. Two easy examples would be one, allowing an application to query audit data within the network to see that a given user has a secure network connection before granting access to a sensitive area. The second is the application PDP informing the network of the systems the user has access to; the network could then prevent IP connectivity to disallowed applications. (Note: server virtualization will make this tricky.)
5. A single PDP brokers policy decisions for networks and applications. I doubt we’d ever get here for all network and application requests (nor would we likely want to) but it seems likely that subsets of applications and networks will share a common PDP. This PDP could then share policies with other PDPs inside or outside the organization.

So as I was saying earlier, this isn’t going to happen all at once. I’d also expect different organizations to go different lengths down this road based on their culture, politics, and business needs. In general based on my dealings with customers, there is a definite desire to make this happen primarily for business efficiency and compliance.

Technorati Tags: AAA, Identity Management

I presented Identity Management for Networks to the Network Applications Consortium (NAC) late last week. The presentation is very similar to others I’ve posted recently so no need to download it if you’ve looked at anything I’ve done recently. What is new is my answers to the presenter questions the NAC posed to everyone at the conference. As the questions are fairly interesting, here they are complete with my answers in italics.

1. Do you see any differences in how the authorization policies of networks vs. applications should be engineered, managed, and provisioned? Network policies are broader today due to limitations of the technology and understanding of the business roles. Eventually network policies will be merged with application policies.
2. Are there any advantages or drawbacks in the flow of the access request being sent to the PDP first or the PEP first? PDP first requires basic authorization to route the request from the network edge which may be suboptimal.
3. Do you see declarative authorization interpreting and enforcing more finely grained authorization policies than they support today? Yes though this is as much a challenge for enterprises to understand their roles as it is a technical challenge to support the fine-grained authorization.
4. Should SAML authorization assertions, and requests for authorization assertion, be used in the communication between PDPs and PEPs? If not, what should be used? For networks, SAML will be used in the future but perhaps more for PDP to PDP communication in a federated model than for PDP to PEP communication. In the network space RADIUS has traction simply because it is so ubiquitous.
5. How can we meet our need for flexibility to deploy centralized and/or de- centralized approaches within an enterprise and across enterprise customer, supplier, or channel partners using different platforms? Policy portability through XACML and authorization assertions through SAML can address much of this, challenges here are more at the organizational level.
6. Comment on the NAC’s best practice of locating the PEP as close to the resource as possible. For networks, it may make more sense to locate the PEP as close to the point of network access as possible to reduce exposure to threats. If you consider the network the resource then our best practices are aligned.
7. Comment on the NAC’s best practice of balancing between availability and performance when selecting the location of the PDP. This makes perfect sense, distribution of the PDP may be key depending on the application.
8. Comment on the NAC’s best practice of having platform agnostic PAPs and PDPs, loosely coupled with access management product offerings (e.g., WAM products). This allows for the independent evolution of PAP, PDP, and PEP technology, without disrupting the other components. This is the only way this can scale long term, particularly the vendor neutrality between the PDP and the PEP. Standards for access control formats need more attention.

Technorati Tags: AAA, Identity Management

Tim Greene has an article over at Network World on how a student at the University of Portland bypassed a Cisco Clean Access (CCA) NAC check to get on the network and got suspended as a result. Simple device software checks, such as those done by CCA were never meant to provide 100% security. Of course no security measure provides that level of protection. Device software checks were designed to prevent the inadvertent user with an out-of-date system from getting on the network. A user bent on introducing malicious code into your network isn’t going to be stopped easily. As I’ve wrote about endlessly, security is a system, not one product. One tenet of good security analysis is to assume that one layer of protection within your environment completely fails. How the rest of your security system picks up the slack is a very telling metric regarding the overall security of your network.

As NAC becomes more pervasive, so will the techniques to bypass its checks. The hope is that those individuals with the technical competence to bypass the checks are also competent enough not to have their machines compromised. How true this is remains to be seen.

Technorati Tags: NAC

In case you have an aversion to the PDF format my article was originally posted in, it is now up in HTML form. I haven’t seen the print version in the mail yet, but hopefully that will be soon.

Technorati Tags: AAA, Identity Management

The notion of applying the same concepts to networks as found in IdM for applications is gaining momentum. As I talk to prospective customers and at speaking events I get questions like, “How is this different from a RADIUS server?” much less often. Folks are starting to grasp the interdependency of identity, policy, authentication and authorization and the requirement to add a layer of intelligence to networks in a heterogeneous way. Last year Eric Norlin started a conversation about the linkages between NAC and identity management and suggested the terms NIdM and AIdM to describe the two elements and their relationship to the broader IdM space. One of my posts from September of 2006 has all the relevant links. He’s staying abreast of the topic as well with a related post just last month.

Since then I’ve been trying out the NIdM term as a way to describe what my company does and through some trial and error I found that putting the “N” last increases understanding significantly: so I now say “Identity Management for Networks” rather than “Network Identity Management.” Perhaps the latter term has too much of a connotation of IPAM and MAC address databases where as the “for Networks” puts a qualifier on a term that most within IT already understand.

I put together a presentation for the SecureIT conference which attempts to map out what IdM-N is and how it relates to a legacy RADIUS server as well as your traditional IdM investment. I’ve since presented a variation on the same theme last week at the New York Metro chapter of the ISSA. At that conference there was a lot of head nodding as well as a customer presentation on IdM in general by Dennis Brixius (CSO at McGraw Hill). Dennis spoke to the need for identity in networks which was great as we served to reinforce some of each other’s points.

Tomorrow I’m presenting the same topic at the Network Applications Consortium’s spring conference. Many of the presenters and attendees at this conference are well versed in IdM for applications and I expect to learn a lot. While over the mid-term I see IdM merging into a single entity that comprises the entire space, it will take us a little while to get there. In the interim, finding ways to link network and application elements through the adoption of standards makes a lot of sense.

A written version of the components in IdM-N can be found in the IPJ article I referenced in an earlier post.

I expect the next six months to be very telling in terms of what terms take hold with customers and more importantly, what applications they are solving with these technologies.

Technorati Tags: AAA, Identity Management

Part one of a two-part article titled Network Authentication, Authorization, and Accounting was just published in the Internet Protocol Journal. I wrote the article as a survey of the entire AAA space and so it covers a lot of ground without spending too much time in one place. If you are new to AAA or are looking for a conceptual model of AAA to help others grasp its concepts, please take a look. Here’s the opening couple of paragraphs:

Network Authentication, Authorization, and Accounting (AAA, pronounced “triple-A”) is a technology that has been in use since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And finally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. This article, the first in a two-part series, focuses on the overall concepts of AAA, defines the elements involved in AAA communications, and discusses high-level approaches to achieving specific AAA goals. Part two of the article, to be published in a future issue of IPJ, will discuss the protocols involved, specific AAA applications, and considerations for the future of AAA.

AAA, at its core, is all about enabling mobility and dynamic security. Without AAA, a network must be statically configured to control access; IP addresses must be fixed, systems cannot move, and connectivity options should be well defined. Even the earliest days of dialup access broke this static model, thereby requiring AAA. Today, the proliferation of mobile devices, diverse network consumers, and varied network access methods combine to create an environment that places greater demands on AAA.

AAA has a part to play in almost all the ways we access a network today. Emerging technologies such as Network Access Control (NAC) extend AAA even into corporate Ethernet access (historically the “trusted” network that set the benchmark level of security that all other types of access had to match). Today, wireless hotspots need AAA for security, partitioned networks require AAA to enforce segmentation, and remote access of every kind uses AAA to authorize remote users. Continue to IPJ

Technorati Tags: AAA, IPJ

With the college basketball men’s national championship game tonight, Network World posted a cute article outlining some statistics on both school’s networks. Worth a quick skim at least. Interesting bit of info on the anticipated size of the OSU network:

We are actively building out a Wi-Fi network on the Columbus campus that will reach over 300 buildings, 25 million square feet, and 1,700 acres. The network could scale to 10,000 access points and support 100,000 simultaneous users within five years. Currently we have over 2,500 Aruba access points installed, with 100% of our residence halls covered with wireless. The network is being designed to support 802.11a/b/g and voice services.

Technorati Tags: 802.1X, wireless