...
In order to transport the authentication request of a user from the Service Provider to his Identity Provider and the authentication response back, a hierarchical world-wide system of RADIUS servers is created. Typically every Identity Provider deploys a RADIUS server, which is connected to a local user database. This RADIUS server is connected to a central national RADIUS server, which is either in turn is connected to a European (or an upstream (European/global) RADIUS server or can connect to other RADIUS servers dynamically (using the protocol RADIUS/TLS). Because users are using usernames of the format "user@realm", where realm is the IdP's DNS domain name often of the form institution.tld (tld=country code top-level domain; both country-code TLDs and generic TLDs are supported), the RADIUS servers can use this information to route the request to the appropriate next hop in the hierarchy RADIUS server until the IdP is reached. An example of the RADIUS hierarchy is shown in Figure 2.1.
To transfer the user's authentication information securely across the RADIUS-infrastructure to their IdP, and to prevent other users from hijacking the connection after successful authentication, the access points or switches deployed by the SP use the IEEE 802.1X standard that encompasses the use of the Extensible Authentication Protocol (EAP). Using the appropriate EAP-method either a secure tunnel will be established from the user's computer to their IdP through which the actual authentication information (username/password etc.) will be carried (EAP-TTLS or PEAP), or mutual authentication by public X.509 certificates (which is not vulnerable to eavesdropping) will be used (EAP-TLS).EAP is a container that carries the actual authentication data inside, the so-called EAP methods. There are many EAP methods an IdP can choose from.
eduroam requires that the chosen EAP method must allow
- mutual authentication (i.e. the user can verify that he is connected to "his" IdP whereever the user is
- encryption of the credentials used (i.e. only the user and his IdP will see the actual credential exchange; it will be invisible to the Service Provider and all intermediate proxies)
Some popular EAP methods in use in eduroam are
- PEAP ("Protected EAP") - a Microsoft protocol that establishes a TLS tunnel, and sends usernames and passwords in MS-CHAPv2 hashes inside)
- TTLS ("Tunneled TLS") - an IETF protocol that establishes a TLS tunnel, and sends usernames and passwords in multiple configurable formats inside)
- TLS ("Transport Layer Security") - an IETF protocol that authenticates users and the IdP with two X.509 certificates
- FAST ("Flexible Authentication via Secure Tunneling") - a Cisco protocol that establishes a TLS tunnel, and sends usernames and passwords in a custom way inside)
RADIUS transports the user's name in an attribute User-Name, which is visible in cleartext . It also transports to all intermediate hosts on the way. Some EAP methods allow to put a different User-Name into the RADIUS packet than in the EAP payload. In that case, the following terms are used:
- outer identity: this is the User-Name in the RADIUS packet and visible to all intermediate parties
- inner identity: this is the actual user identificator. It is only visible to the user himself and the Identity Provider
When using such EAP methods, and activating this option, the real username is not visible in RADIUS (it will only see the outer identity). Outer identities should be in the format "@realm" , which is encrypted and not visible to intermediate servers, only to the IdP server. In order to ensure privacy, it might be desirable not to put the real username in the RADIUS User-Name attribute (this attribute is the "outer" identity). Instead, it might be preferred to put @realm in this attribute (nothing left of the @ - this is the IETF-suggested formatsign, but the realm is the same as with the actual username). The realm part still must be the correct one as it is used to route the request to the respective home serverIdentity Provider. Once the IdP server decrypts the TLS tunnel in the EAP payload, it gets the real user name - the " inner " identity and can authenticate the user.
After successful authentication by the Identity Provider and authorisation by the Service Provider, this SP grants network access to the user, possibly by placing the user in a specific VLAN intended for guests.
...