eduroam service providers offer network connectivity to end users that are affiliated with other organizations. They do this knowing that all use can ultimately be traced to users who are known by their identity providers; even if these users are not known to the service provider. This traceability is needed by service providers for legitimate purposes, such as supporting end users and tracking unacceptable uses of the network. 

Nonetheless, users are entitled to privacy, and identity providers should protect their users against illegitimate uses of their identities. This article discusses how users are identified in eduroam; how this identification can sometimes weaken privacy; and what steps can be taken to preserve it. 

User identification in eduroam 

When a user connects to eduroam, the device transmits certain information to the service provider that may identify them or their device. This includes 

  • the device’s MAC address 
  • the user’s Network Access Identifier (NAI), and 
  • authentication data sent in cleartext, intentionally or unintentionally. 

The MAC address (https://en.wikipedia.org/wiki/MAC_address) is usually a persistent identifier. Although it does not expose the user’s identity directly, it can be used to track a device within and between networks.  

The NAI (https://www.rfc-editor.org/info/rfc7542), which takes the format <user>@<organization>, is used to route authentication requests to the user’s identity provider, on the basis of the <organization> component’s value. The <user> component often takes the value of the user’s network login. Therefore, an NAI can be very identifiable (e.g., “jsmith@college.edu”). 

Finally, some EAP authentication methods expose the user identity by design. This is generally isolated to legacy methods, such as EAP-MD5 (https://www.rfc-editor.org/info/rfc3748) and EAP-MSCHAPv2 (https://datatracker.ietf.org/doc/html/draft-kamath-pppext-eap-mschapv2). However, it also includes EAP-TLS (https://www.rfc-editor.org/info/rfc5216), which is widely used. 

In the case of EAP-TLS, a persistent user identifier is included within the subjectAltName field of the client certificate. This is a consequence of how version 1.2 of the TLS protocol operates (https://www.rfc-editor.org/info/rfc5246). The field typically takes a value of the user’s network login or email address, and is transmitted in cleartext, even over WPA-Enterprise networks. Consequently, it is trivial for an attacker to collect user identities and the associated MAC addresses. 

The MAC, NAI, and EAP authentication data are provided by the end user’s device. In addition to these, the user’s identity provider can also, at the request of the service provider, assert an identifier for the end user. This identifier, which is delivered to the service provider within the Chargeable User Identity (CUI) RADIUS attribute (https://www.rfc-editor.org/info/rfc4372), is a pseudonym that uniquely identifies the user. 

The CUI is a non-human readable (“opaque”) cryptographic hash that is targeted to the service provider. Each service provider therefore receives a different opaque value for the same user. This allows service providers to recognize a user as one that they have seen before, without knowing who the user is; while preventing service providers from colluding to track users. This enables legitimate purposes, such as blocking malfunctioning devices and generating accurate usage statistics. 

Protecting end user privacy 

Many operating systems and devices now support MAC address randomization. A device with this configured will periodically change its MAC address. The capabilities of operating systems and devices differ, but usually randomization can be set globally, for all networks, or for specified networks. MAC address randomization makes it much harder for service providers to track devices, improving user privacy. 

The most widely supported EAP authentication methods, EAP-PEAP (https://datatracker.ietf.org/doc/html/draft-josefsson-pppext-eap-tls-eap) and EAP-TTLS (https://www.rfc-editor.org/info/rfc5216) support anonymization of the NAI. This allows the user component of the NAI to be set to any value, such as “anonymous@college.edu”. It can even be null (i.e., “@college.edu”). eduroam only uses the organization component. In most instances, the EAP authentication method securely transmits the user’s real identity to the identity provider within an encrypted tunnel. 

In common with most modern EAP authentication methods, both of these methods comply with all the “mandatory” and “recommended” requirements and “optional features” as described in “EAP Method Requirements for Wireless LANs” (https://www.rfc-editor.org/info/rfc4017). The relevant property for privacy is “End-user identity hiding”. Like EAP-TLS, these methods use TLS but they do not require the use of client certificates. Instead, the user’s password is securely tunneled within a TLS session. Consequently, they do not expose a subjectAltName field. 

EAP-TLS 1.2, on the other hand, does require transmission of a clear text client certificate containing a subjectAltName field that uniquely identifies the user.  This deficiency has recently been addressed by TLS 1.3 (https://www.rfc-editor.org/info/8446), which provides for encryption of the client certificate in the TLS handshake, and support included within the latest update to EAP-TLS (https://www.rfc-editor.org/info/rfc9190). However, EAP-TLS 1.3 is not yet widely implemented, and it is likely to take some time before it replaces the previous version currently deployed in users’ devices and identity providers’ RADIUS servers. 

Service providers can request a Chargeable User Identity (CUI) for a user at the time of authentication from the identity provider. A CUI uniquely identifies a user to a particular service provider, but does not allow tracking a user across multiple service providers. The CUI can be operationally helpful for service providers, but identity providers are not obliged to return one. 

Best practices for identity and service providers 

Identity providers can enhance their users’ privacy by taking the following steps. 

  1. Encourage users to enable MAC address anonymization on their devices, where available. If possible, require it for organizationally managed devices. 
  2. Ensure that you support the use of anonymous NAI, and encourage your users to configure it. If possible, require it for organizationally managed devices. 
  3. Do not use insecure EAP authentication methods. Instead, use a method that complies with the “mandatory” and “recommended” requirements and “optional features” as specified in RFC4017, such as EAP-PEAP or EAP-TTLS. 
  4. If you are using EAP-TLS, assess the risk of using EAP-TLS 1.2 until version 1.3 is widely deployed.  
  5. Adopt and promote the use of the eduroam Configuration Assistance Tool (https://cat.eduroam.org). This tool simplifies (2), (3), and (4) by helping users to configure their devices correctly.  
  6. Consider whether to support returning CUI to service providers. Although it reduces user privacy, the loss is marginal and it offers significant benefits to service providers. Even if you do not wish to send CUI to all service providers, you could still return it to a subset (such as other collaborating organizations). 


While identity providers are responsible for their user’s privacy, service providers may want to consider the following. 

  1. MAC address randomization is likely to become prevalent. This could result in some operational challenges, such as exhaustion of DHCP address pools. Explore what your vendors are doing to accommodate MAC address randomization. 
  2. Consider what information you are logging and the associated retention policy. You can help preserve user privacy by logging the minimum information. Service providers are only required to log the following: the time of authentication request and response; the outer EAP identity (User-Name attribute); the MAC address (Calling-Station-Id attribute); the type of authentication response (accept or reject); the IP address allocated to the client and any information needed to correlate this to the device (e.g., DHCP logs). The minimum retention time is six months, unless regulations require otherwise. 
  3. If you would like to request CUI from identity providers, append the following attributes to the Access-Request: 
  4. An empty instance of the CUI attribute (RADIUS attribute 89) 
  5. A populated instance of the Operator-Name attribute (RADIUS attribute 126)