The following sections provide detailed information for the two roles eduroam IdP and eduroam SP, respectively.
The eduroam SP section explains the obligations for an eduroam SP and lists what should be taken into account in a wireless LAN deployment, and the set up of a RADIUS server for use in eduroam.
The eduroam IdP section explains the obligations for an eduroam IdP, the set up of several popular RADIUS servers, and means to provision configuration details of supplicants to end users.
In order to test the eduroam setup from an end user perspective, please check out the Section How to offer support to end users. Also use this for helping end users get on to the newly-established eduroam network on campus.
There are use cases for securing access to a wired port in the same way as to a wireless Access Point. This use case is often not primarily intended for roaming though, as it is much more difficult for an incoming guest to locate a physical port in a building than it is to pick up a wireless broadcast signal from an access point. Much rather, an IdP who has already turned his users into eduroam users might want to benefit from the existing configuration in his end-users' devices to secure dormitories and similar locations, where finding the attachment point is less of an issue.
The eduroam consortium is media-agnostic and welcomes wired eduroam. Wired eduroam works a lot like wireless - instead of an Access Point with 802.1X support, an eduroam SP needs a wired switch with that same 802.1X support. The SP configures it to authenticate the physical port users to the same RADIUS server that his access points do, too (i.e. the switch becomes a RADIUS client for the eduroam SP RADIUS server) - and that's all, the switch is then part of the eduroam infrastructure proper without further changes needed.
Experience for end users is somwhat grim compared to wireless.The IEEE 802.1X revisions of 2001 and 2004 lack some of the features eduroam users are used to in the wireless world where IEEE 802.11 augments the missing features of IEEE 802.1X. The following text describes the shortcomings of versions prior to IEEE 802.1X-2010, because as of this writing, no single switch and/or supplicant is known which would support the new features of IEEE 802.1X-2010. Deployers of wired eduroam should be aware of the following differences for end users.
When connecting to eduroam, users are usually made aware that the network they are connecting to is an eduroam network - simply by observing the SSID "eduroam" occuring on their computing device. In wired IEEE 802.1X networks, the concept of SSIDs does not exist. The user needs to plug in his device and try to connect in the usual way (using his supplicant, the usual EAP configuration and his eduroam credentials) - which will work on the configured eduroam ports, but not at any other network ports. eduroam Service Providers are advised to give clear indication which ports in a building are eduroam ports and which are not. One means to achieve this is by putting an eduroam logo besides the ports in question, or announcing the existence of eduroam on a building's wired ports on a signpost near the entrance to the building.
With IEEE 802.1X-2010, so-called "Network Announcements" are supported. After plugging in the device, the user's supplicant is presented with a list of strings which identify the network. This feature provides the equivalent of SSIDs from wireless networks and can help end users identify usable wired network plugs.
Computing devices typically allow multiple independent configurations for the wireless network interface; the configurations are usually seperated by the SSID they belong to. That way, users can configure their eduroam credentials for the "eduroam" SSID, and can have any number of other configurations for other networks at work or at home. In wired IEEE 802.1X, supplicants typically only allow "the" IEEE 802.1X configuration (likely due to the missing network indication as described above, which makes it impossible for the supplicant to determine which configuration is to be used for the wired connection). Users who have a need for multiple wired IEEE 802.1X configurations will probably be dissatisfied with that situation.
With IEEE 802.1X-2010's network announcements, it becomes easy for supplicants to distinguish between different configurations. It is expected that, once IEEE 802.1X-2010 support on the attachment points becomes common, supplicant implementations will follow suit and enable storing and choosing different configurations per network identifier. This is implementation-specific per supplicant though, and support for this can and will vary.
In IEEE 802.11 enterprise wireless, the end-user's network payload data is encrypted between his device and the Access Point. This happens automatically when using EAP and RADIUS, and is also highly desirable for the user's security because it prevents snooping of his private data by bystanders in the broadcast domain of the access point.
In wired networks, user payload is not broadcast, but is instead directed on a copper or fibre wire directly to the switch. This makes encryption of the payload a less pressing problem. Consequently, IEEE 802.1X does not foresee encryption of user payload data.
This is not particularly alarming because of the point-to-point nature of wires, but is a difference to the wireless use case deployers of IEEE 802.1X should be aware of.
IEEE 802.1X-2010 includes support for a previously standalone feature called "MACsec" (previously IEEE 802.1AE). This feature allows to encrypt payload data on the wire between the end-user device and the switch. Implementations of supplicants and switches supporting this feature have not yet been observed in the wild though.