802.1X has been around for 9 years now yet it remains sparingly deployed in the wired network.  Despite its poor market penetration on the wired network thus far, I believe 802.1X is nearing a time of wide spread deployment.  Here are two top level reasons why its way to early to give up on 802.1X, and why I think it will flourish.

1. Organizations genuinely need it 

Many large organizations have known they need 802.1X for years, but have been waiting for vendors to provide a more mature system.  This leads me to reason number two. 

2. Vendors still want to sell it 

Despite the fact that 802.1X itself is quite simple, there are numerous areas of complexity in 802.1X deployments that provide opportunities for companies to differentiate themselves.  The more these features can be built into other products like switches and servers well, you know the deal...

802.1X also uniquely creates ‘stickiness’ with other components of the IT system and allows vendors to position our beloved ‘solutions’ instead of ‘products’.  Here are a few quick examples:

• Having a supplicant (client) that is tightly integrated with the authentication server and provides extensions such as NAC attributes
• Guest Access products that allow guest/contractor provisioning as well as device provisioning that can also be integrated with the switches and/or authentication server
• RADIUS accounting information that can provide a more robust troubleshooting and administrative system by providing detailed information from switches and RADIUS servers and be aggregated and summarized in a SIM product

Whichever vendor is the first to deliver a comprehensive 802.1X solution inclusive of 802.1X supplicant, switches capable of authenticating EAP and non-EAP endpoints, AAA, and management/administration is going to win big; not just with client software, RADIUS and management servers, but with large network upgrades.  The major vendors have all made 802.1X-centric acquisitions 802.1X including Cisco (Meetinghouse), Juniper (Funk Software), and Symantec  (Sygate) and they’ve all completed the first phases of integration between these components and other peripheral systems or associated products.  It will be fascinating to see how they all fare in the next 12-24 months.

Granting network access based on the MAC address is not new; it’s been around since the days of LAAs in Token Ring and Ethernet hubs (probably before that too, but that’s as far back as I go).  Secondly, it is not terribly secure when compared to other network access methods like EAP, and SSL but the increased deployment of MAC authentication in enterprise networks is definitely happening and for some good reasons.

Instead of locking MAC addresses to Ports, which has proven to be administratively cost prohibitive MAC Authentication leverages a database of MAC addresses either on a discreet system like Great Bay’s Beacon Endpoint Profiler or a white-list of MAC addresses that reside on the RADIUS server itself.  On switches its called MAC-Auth-Bypass in Cisco speak, but the major networking vendors all have their own flavor of MAC Authentication on their switches

The primary motivators we’re hearing from enterprise organizations for deploying MAC authentication are:

For increased security - 

Although not as strong as supplicant-based 802.1X, if you subscribe to the locked door theory (you know - the one that says most criminals will check the door and if its locked they’ll move on without ever checking to see how strong the lock is) then MAC authentication is a meaningful addition to the security of the enterprise LAN.  If you can detect MAC Spoofing, which is the way to defeat MAC authentication, then MAC authentication is that much more secure.

As a precursor to stronger authentication or NAC - 

MAC authentication is an important first step in a phased approach to NAC and/or 802.1X.  In some cases, customers are using MAC authentication to vet the 802.1X control plane prior to enforcing authentication or to overcome challenges such as PXE boot or login scripts that prove difficult to accommodate in an 802.1X deployment.  In addition, it remains the method for granting network access for devices such as printers, phones, UPS, WLAN APs, etc for the life of the deployment.

To provide an answer to the question “do you know what is attached to your network?” - 

This question, and the ones related to it, such as “how do you know when a new device is plugged in?”, “how do you maintain a history of endpoint addressing and locations?” and “how do you know which endpoints in the network are actually yours?” can all be answered through the deployment of MAC authentication.  Depending on how you gather and maintain the database of endpoints this can be a system that provides important contextual data beyond the MAC such as identity, IP address, and location.

Too much diversity for a client based approach -

It isn’t uncommon for companies to research the deployment of 802.1X and/or NAC and realize that the endpoint landscape in their network is just too diverse to make the deployment of client meaningful.  Although this can be true in any network the most common candidates for making this decision are health care (due to patient care systems), Energy (really anyone with SCADA systems), and manufacturing all of which have highly diverse endpoint types 

There are those that will look down their nose and proclaim that MAC authentication isn’t secure, but I would argue that it’s a meaningful addition to enterprise network security and dramatically easier and less risky to deploy than many of the alternatives.

Gartner (Lawrence Orans)recently published a paper entitled “Introducing the Identity Aware Network”, which can be found here if you subscribe to Gartner’s services or are willing to pay to read it:

http://www.gartner.com/DisplayDocument?ref=g_search&id=834420  

Alternately, you can read Tim Greene’s article about it here for free:

http://www.networkworld.com/newsletters/vpn/2009/011209nac1.html  

Although it's tempting to lament the points in the paper that I disagree with or feel needed more consideration in the paper, the central theme that Mr. Orans is highlighting is so compelling to the management and administration of the enterprise network that I’d like to focus on that instead.  Since the ratification of 802.1X and subsequent emergence of NAC, the vast majority of vendors and customers have missed the fact that identity, one of the most readily available by products of a deployment of 802.1X/NAC, can unlock numerous efficiencies, support compliance initiatives, and improve IT security.   

The ability to map connectivity and device attributes such as IP address, MAC address, Machine Name, etc to the name of a person is a huge leap forward in troubleshooting IT systems, incident response processes, and compliance initiatives.  To highlight this, consider the following scenarios:

1.     Someone calls the help desk because they can’t print or can't reach some network resource.  The help desk technician, instead of asking for the users MAC Address, IP Address, Ethernet Jack, Printer Name/Queue they’re trying to print to, etc, they can simply ask “what username do you use to login in the morning?”.  Because of the authenticated session, the additional information required to initiate this troubleshoot, such as the items I mentioned, are already associated withthe username and if they don't provide an immediate resolution, they certainly provide a meaningful start to finding a resolution.

2.     A security incident is received where an IP address has been detected doing something or other that is either undesirable or impacting network availability.  Instead of going through the usual hoops of locating the IP, looking up the current assignment in DHCP and/or ARP tables, scouring SAT tables to find the port to which the device is attached, tracing the cable to the patch panel, finding the jack, etc. the person working on that incident could simply search for the IP and learn which person was using the machine.  Instead of all the aforementioned gymnastics you could simply call the person and tell them to knock it off.  <reality check> ok, so the person would really email them and CC his/her boss –people don’t call each other anymore.

3.     Given that there is a real migration away from traditional ‘phones’ (I only use a Blackberry and Skype and I don’t think I’m terribly unique in doing so) the concept of E911 is in real need of an overhaul.  My recollection is that when I signed up for Skype voice calling it said “not for 911” or something similar. So, why can’t a person get help when they’re incapable of speaking, but can somehow dial 911, click “call” in Skype, send a text, or even (I can't believe I'm writing this) send a tweet.  I admit, it seems hard to believe that someone would text rather than call, but if you think about it, a call either connects or not whereas a text endures until the person sees it and if you can't speak a voicemail isn't an option.  While this scenario is admittedly more obscure than the aforementioned, one can easily see that the raw materials for such a system being a strong IP-to-Identity binding.

Additionally, although not mentioned in the Gartner paper, the notion of Identity also needs to be expanded beyond the person.  Everything connected to the network has an identity (printer, WLAN AP, VOIP phone, etc.) and those values are often as important as the person-centric identity.  I’ll stop that thought right there before it becomes a Great Bay product pitch, but the applications for identity are definitely wider than people and organization.

So, the idea of the Identity-Aware Network is pretty important from my perspective.  Enterprise organizations will determine whether the cost/benefit is compelling enough, but my sense is that once customers fully understand the value it will quickly make its way up the priorities list on more than a few whiteboards.