IT Jobs
802.1x - Port Based Authentication
Connect your WLAN to your RADIUS
By Louise McKeag, Techworld | Techworld
Published: 00:00 GMT, 13 May 04
If you have users who are constantly shifting from one part of the office to another, or need the same access in conference rooms as they have at their usual desk, you either have to provide more or less unrestricted network access everywhere, or find some way of dynamically controlling who gets access to what. And if you have to provide different levels of access to staff groups, contractors and visitors, it's going to have to be the latter.
Hence 802.1x. The trouble is that in itself 802.1x doesn't actually do this. Instead you have to rely on the extensions to 802.1x provided by your network infrastructure manufacturers. So what do you need to look for to ensure your network can do what you really need?
802.1x standard
802.1x is basically a standard for carrying EAP (see The EAP Heap) over a wired or wireless LAN. It's an authentication protocol - it doesn't actually care how you authenticate the client, be it password-based or using OTP (one time password) tokens.
Terminology-wise, the supplicant (i.e. the client) talks 802.1x to its attached authenticator (the LAN switch or access point), which then passes the EAP authentication information to an authentication server (a RADIUS server). The authenticator will allow only 802.1x protocol packets to be passed from the supplicant onto the network until authentication has been confirmed, at which point it will change its port status from unauthorised to authorised and let normal data traffic through.
There are a couple of issues here. According to the standard, all that will actually happen at this point is that the port to which the user is connected will, once authorised, be put into the VLAN it was pre-configured with - i.e. it's an on/off mechanism. There's nothing in the standard to change the VLAN to suit the user.
Also, if the port is set for 802.1x and the client doesn't support it, there will be no authentication process, and the port will remain disabled. It works fine the other way round: an 802.1x client connected to a non-802.1x port will try to send an authentication request, but when it doesn't get a response, it will just behave as if it had successfully authenticated and start normal data transfer. But if you want to offer access to third party users who aren't part of your 802.1x system, you can't.
802.1x extensions
So, as with most standards, manufacturers have added their own features to make things more workable. And you need to verify from any potential supplier, which of these they can do.
VLAN support
As a bare minimum you're going to want the ability for ports to dynamically change which VLAN they are in based on user information. That way you can be sure that regardless of where in the building he is, if your HR manager needs to be in the HR VLAN he can be, without compromising staff confidentiality by risking non-HR personnel using it.
Guest VLAN
If you want to offer visitors and contractors Internet access so they can reach their own company network, you don't particularly want to give them the ability to surf your internal LAN too, looking to see what's about. So some vendors offer the ability to set the system so that if a user tries to connect but doesn't have an 802.1x client, they will be put into a 'guest' VLAN that you can set up with access only to your Internet router, say.
Be wary of how this feature is supported. While some companies claim Guest VLAN support, there can be a difference between a client with no 802.1x capabilities, and one which does have 802.1x for its own home network, but which isn't registered on your RADIUS server. If a client does respond to an 802.1x request from a switch port, say, but can't authenticate, that may cause the port to stay disabled. So clients with 802.1x but not credentials for your network may even be denied access to the Guest network, while one that just ignored the authentication request altogether would be allowed some limited access. Make sure you know exactly what's on offer.
Access Control
Some vendors also allow you to set filters dynamically on a port depending on who has logged in, so that you can apply access lists over and above VLAN membership. This could be a useful feature where you could, for instance, apply rate limiting on your Guest VLAN ports, so that visitors can't swamp your Internet connection.
Voice
If you're in the process of looking at Voice over IP, you'll be recommended to put all your voice traffic into separate Voice VLANs for ease of management and control. But that means having two VLANs on a port - one for voice, one for data. This isn't part of the 802.1x specification, and those manufacturers who support it do it at different levels.
At the moment, the voice VLAN is usually a static configuration, but there is work afoot to put 802.1x supplicant code into IP handsets, so that that's dynamic too. Again, it is best to find out what's on the roadmap of your prospective supplier.
Port security
Some vendors push the ability to have port security (i.e. only specified MAC addresses allowed on certain ports) compatibility with 802.1x. To be honest, this doesn't seem to be such a great thing. Port security is great for the likes of server connections, where things are pretty static, but it's sort of at odds with the idea of full mobility that 802.1x offers. So think long and hard about whether it's actually any use in your environment before you let some salesman persuade you that it's the differentiator over the competition that should make you choose his product range.
As users demand more and more flexibility, 802.1x is definitely worth looking at - but make sure you know which variant you're being sold and just what it can and can't do before you go for a full implementation.
.gif)
Add your commentComments