Page 452 - From GMS to LTE

438 From GSM to LTE-Advanced Pro and 5G

In company environments, the certificate used in WLAN networks is usually signed
by a private certificate authority and its certificate is previously installed in the device.
If a public certificate authority was used to sign the key, which would be the case at
public conferences, the certificate authority’s key is usually already installed in the client
device. This is because such a certificate authority also signs certificates used for
authenticating web servers. As anyone can get a signature for a certificate from a public
certification authority if they are the owner of the domain specified in the certificate, an
additional client‐side configuration is required to compare the domain name contained
in the ‘alt‐subject’ parameter of the certificate to an expected value. This configuration
can either be made manually or with the help of a configuration file. The format of the
configuration file depends on the operating system. The configuration parameters for
802.11x EAP‐TTLS for Debian/Ubuntu are as follows:

[802-1x]
eap=ttls;
identity=x
ca‐cert=/etc./ssl/certs/StartCom_Certification_Authority.pem
altsubject‐matches=DNS:radius.c3noc.net;
phase2-auth=pap
password-flags=1
Once the client device has accepted the server certificate (packet 14 in the trace) an
encrypted handshake message that is client‐specific is exchanged. For this dialog, the
client uses the public key that was part of the certificate to encrypt the message.
Decoding the packets on the network side is only possible with the private key. As
the private key is never sent over the air an attacker is prevented from using a copy of
the certificate for a rogue access point.
Afterward, the standard four‐step EAPOL WLAN messaging is used to activate link‐
level wireless encryption, based on an individual secret exchanged during the TTLS
process. Packet 22 shows the first encrypted packet exchanged between the access point
and the client device, a DHCP message to get an IP address. As the trace was done on
the client device the decoded version of the packet is shown. Once the IP address has
been received the connection is fully established and user data packets can be exchanged.

6.7.5 WPA and WPA2 Enterprise Mode Authentication – EAP‐PEAP
Another Wi‐Fi authentication method used in practice is the EAP – Protected Extensible
Authentication Protocol (EAP‐PEAP). It is used, for example, by the popular Eduroam
system (https://www.eduroam.org), which enables students of participating universities
to get Internet access over WLAN on their own campus and at any other university
around the globe that also uses Eduroam for WLAN authentication. As all participating
locations use the same SSID (‘eduroam’), no reconfiguration is necessary when roaming.
Like EAP‐TTLS described above, Eduroam uses EAP‐PEAP with certificates to authen-
ticate the network towards the user and a username and password to authenticate a device
towards the network. To prevent man‐in‐the‐middle attacks, devices need to be config-
ured to accept only the certificate of the user’s home university, even when roaming abroad.
As Eduroam is a federated system there is no central authentication system. Instead,
each university has its own authentication servers that are reachable over the Internet from