Deviations from the Original Design

normal username/password pair.

7.3.2 VPN Server

The VPN server used in this prototype is the server part of the OpenVPN package (actually, the same program as the VPN Client, but with dierent parameters). It is easy to congure, and has plugin support and can be extended with authentication scripts, which allows for easy integration with the Authenticator.

Before the VPN Server can be started, a few steps have to be completed. First, a CA certicate and a server public/private key pair have to be created as shown in appendix A.1, and the conguration le has to be created. A sample conguration le can be found in appendix A.3. Also, the user authentication script has to be put in the scripts directory. This script is shown in appendix A.4. The script requires perl support in the operating system.

When the VPN Client connects to the VPN Server, an encrypted tunnel is created between the client and the server. Over this tunnel, the Client sends its username (the IMSI) and its password (the MD5-hashed key) to the server. When the server receives the authentication request, a script is called with the IMSI and the key-hash as parameters. This script connects to the Authenticator and asks for the key associated with that specic user. If the user is not authenticated, a null value is returned, and the VPN Server disconnects the client. If the user has authenticated at the Authenticator, the key byte sequence is returned to the VPN Server. The hash of this byte sequence is then compared with the hash received from the client. If they are equal, the server has proof that the client is the same as the authenticated user.

7.4 Deviations from the Original Design

In the prototype implementation, a few deviations from the original design had to be made. Some because of time constraints, and other for practical reasons.

7.4.1 EAP key-derivation algorithms

As mentioned in section 7.2.2, one of the algorithms used in the generation of EAP messages has not been created according to the RFC (RFC 4186 [HS06]). This is the pseudo-random number generator function used to derive the Transient EAP Keys, the Master Session Key and the Extended Master Session Key from the Master Key. The Master Key is created according to the RFC, but is used directly for calculating the MAC. This should be redesigned in a non-prototype implementation.

This was done because of the complexity of the algorithm, and because implementing the EAP protocol was not part of the assignment this part was given low priority. Implementing this function later is possible.

7.4.2 Creating SIM Authentication Triplets

Because of time constraints, integration with an Identity Provider or AAA server was not implemented in the Authenticator. Instead the authentication triplets are generated in advance, and stored in a le. During authentication the Authenticator reads this le, lters out the triplets with the IMSI equal to that of the user, and selects three random ones to use.

Before trying to authenticate the SIM, it is vital to the success of the authentication that the Triplet le is rst generated on the Supplicant, then copied from the Supplicant to the Authenticator. If the le already contains Triplets with the IMSI of the SIM used, this step can be skipped. If the dummy interface is used, this must be done every time the Supplicant is restarted, because of the random IMSI of the dummy interface. Integrating the Authenticator with an Identity Provider later should not be too dicult. An alternative TripletSource class forwarding the EAP requests from the supplicant to the Identity Provider could be written and included in the Authenticator.

7.4.3 Verifying User Authentication Status

It was initially planned to use Radius as a way to query the Authenticator for the user authentication status. Because of a lack of Radius libraries for .NET, this was not implemented. Instead, a simple query/response mechanism is used to send the key of the connecting user, described in section 7.2.2.

Radius should have been used here, in order to improve compatibility with other VPN Server authentication mechanisms, but writing a Radius implementation would have taken too much time.

7.4.4 Authentication Key Usage

In this implementation, the key derived from Die-Hellman during the EAP authen- tication is not actually used as the VPN tunnel encryption key, as originally planned. This is due to the strict authentication sequence OpenVPN uses. First it establishes an encrypted tunnel based on the server certicate, to validate the server side of the connection. This sequence may also take a client certicate to authenticate the client, but this is not used in this conguration. Then the username and password is sent to the server over the encrypted tunnel (not required if client certicates are used). This is used to authenticate the client.

It was originally intended to use a static pre-shared key for channel establishment, as described in section 6.1.5. However, the pre-shared key solution starts encrypting the data from the rst bit, without performing any parameter exchange in advance. This means that the VPN Server has no way of nding the username without rst having the pre-shared key, as the incoming data stream would only look like random bits. Requiring that the VPN Server should have this pre-shared key in advance would defeat the purpose of this system.

One solution to this could be altering the connection establishment procedure when using secret keys, so the VPN Client could inform the VPN Server of the username

7.5. User Manual 73