Sean Convery

I’ve just posted the talk I’m set to deliver 45 minutes from now at the Secure IT Conference. There are two versions available. The first is the basic pdf file of my slides. The second is the notes version with some additional details (but smaller slides). This contains some of the info I talked to rather than presented on screen. Beware, both of these files are over 6MB in size. I’m trying to figure out why, there isn’t anything terribly complicated in the slides. Given the file sizes, if you haven’t seen the talk I recommend starting with the first version. I also linked this talk on my main page.

On Wednesday the 22nd I’m speaking at the SecureIT 2006 conference in Anaheim. The talk’s title is “802.1x: An IT Rorschach Test.” The following is the abstract: “The IEEE 802.1x standard for network authentication has been lambasted and praised, called both a dangerous diversion of an organizations resources and the foundation for the next-generation of user-based network services. But which is it? Early deployments of 802.1x (particularly in wired environments) ran into significant deployment issues which left some organizations soured to the entire notion of a campus authentication event at the network edge. This coupled with the relative stability of alternatives such as IPsec, SSL-based VPNs, and simpler options such as in-line web authentication have stalled installations and even pilots. However, there are organizations who are getting use out of 802.1x today and have managed to successfully roll out the technology in service of their organizations business goals. This talk will explore 802.1x deployment focusing on the lessons learned from both successful and unsuccessful early adopters. The largest challenges such as exception management, supplicant strategies, directory integration, and AAA infrastructure availability will be explored in detail. Additional topics covered include IT organizational issues, integration with other security technologies, and the direction of 802.1x as a technology (including security considerations). Attendees should have a basic understanding of network security including AAA. Prior 802.1x knowledge is not required.” I’m still polishing the slides but will post a PDF of them after the conference.

I’m off to the IETF meeting in Dallas to attend the NEA BoF. NEA at this point exists as a problem statement with a goal to define a set of standards in the same vein as Cisco’s NAC, Microsoft’s NAP, and the TCG’s TNC. What’s unique about this effort is both Juniper and Cisco are participating (they are two of the coauthors of the problem statement ID). Cisco has not participated in the TNC effort in this same space but Juniper/Funk have. Hopefully this can bring some consistency and ideally interoperability to the two approaches. I reviewed the problem statement draft and it is a good summary of the issues and also the opportunity for standardization.

While talking to folks in the IDM space about the benefits of network identity management I often run into the question James McGovern recently asked: What is the difference between network and application identity and why are they separate? There are a couple ways to answer this; first some background.

Both network and application identity management evolved from a desire to limit the number of authoritative user stores within a system. With application identity management this is achieved–today–primarily by writing hooks into the authentication infrastructure of many popular applications which then leverage a back-end directory to perform central authentication. Network identity management does roughly the same thing today using RADIUS.

In mid to large size organizations the groups who manage the applications and the groups who manage the network and its security are often in different parts of the IT organization. Though this is not ideal long term, today those groups generally do not work well together and as such often solve their problems separately. Though the fundamental drivers are the same, the operational needs of network and application identity are also different. In the network, for example, access rights are enforced across a whole range of different enforcement devices. By speaking RADIUS, an identity management platform gains access to hundreds of different types of network devices. Each of these devices may have its own way of enforcing policy. This is exacerbated by the recent focus within AAA on the second A: authorization. Authorization in today’s identity-aware networks means lots of potential things:

Dynamic VLAN provisioning
Dynamic ACL / QoS provisioning
Host posture standards
Time of day restrictions

The application world also has rich authorization decisions to make but today the application identity management systems lack the network focus and awareness to make a rich policy decision–and to provision the session to enforce that decision–within the network. Longer term standards like XACML can help bridge these two worlds moving forward. Additionally, to the degree both systems support a common directory such as LDAP or Microsoft AD you get a certain amount of integration for free. I expect application and network identities to stay separate for the near future but merge over the mid-term. The benefits of a central business policy defined in one location and then enforced throughout the IT infrastructure are just too compelling.