ISPng

Neutrinet VPN MGMT setup

Intro

This document describes the current implementation of the VPN user management. It is meant to clarify design choices made by the author and to invite a discussion on the items contained within. All of this is subject to change, and will be changed following public discussion.

The software stack implementing what's written below is written by wannes and found at https://github.com/wannes-ds/ISP-NG. Bug reports and pull requests are very welcome!

Browser support

Yes, this is still a thing:

• Firefox 13+
• IE 10+
• Safari 6+

A JRE (Java 6+) needs to be installed and configured to allow for Java applets (see later on).

User signup

I've chosen to implement a system where users can sign up only when having an unlock key, a random string of 10+ chars. This allows us to manage the influx of users when registrations are open to the general public, as to never have more users than we can actually handle. This kind of system is also known to drive demand, as people have shown a greater interest in things when they have to wait (remember the Raspberry Pi). However this may be perceived as too artificial, unfriendly and frowned upon.

If the unlock system is to be maintained and how the actual handout of unlock keys is to proceed is subject of further discussion.

User security

Currently users are required to have one of the following: their eID keypair or a signed keypair by Neutrinet's CA. I consider this to be a hard security requirement, the end user *needs* to have a keypair of his/her own to prevent MITM attacks. Also: if we are going to implement a secure VPN, password auth alone in this day and age is silly to me.

This means that when a user want to open his VPN connection, he will need his eID or have his keypair. eID auth is convenient for roadwarrior configs and/or when there is no fixed computer, as you only need your eID (which is a legal obligation for Belgian citizens) and a cardreader (which might be a slightly bigger problem, though USB card readers can generally be acquired at low cost, if any). We validate the certificate against the Belgian Root CA, so we do have to trust them in order to make this work.

The other option is best, but also requires a bit of work for the end-user. He needs to create a keypair, upload the CSR and then place the signed certificate in the correct place, whilst preferably knowing exactly what he's doing, certainly with regards to private key handling. This is yet to be implemented in the config stack.

User registration

As it is currently unclear if data needs to be kept about the user (following the decision of that European instance), I elected to collect all data that is to be used for identification as a preemptive measure. Even when this registration may **not** be required at this point, it is a bigger inconvenience to the end user when having to enter all that data when we suddenly do need it.

Currently, the following is stored:

• Name (first, middle and last)
• Address
• Date and place of birth
• eID chip number (not used for identification, see further)

The bad news is that to get this data, a Java applet together with a servlet on the backend needs to be used, which means a truckload of scary dialog boxes. Also, because Chrome releases on OSX and Windows are *still 32-bit*, they do not support Java applets. Firefox, IE and Safari will do nicely however.

IP addressing

The user is invited to chose whether he wants an IPv4 address assigned, IPv6 /64 is assigned by default because we have plenty of those.

User is then able to see which addresses he'll get after confirmation (if there are still addresses available).

Relevant API calls:

   PUT /api/address/pool {"version": IP_VERSION, "subnet":"SUBNET/NETMASK"} # puts subnet into pool
   GET /api/address/lease # gets assigned ip addresses and user

User setup

Currently, when the user has finished the registration procedure, he receives an email (sent from no-reply@neutrinet.be) containing the IP addresses given and a link to validate his email address. When validated, he is redirected to the user setup page. The user is able to download the openvpn config file bundle for his platform, with instructions on how it needs to be configured.

The config page automatically renders the appropriate platform section based on the User-Agent, which contains detailed setup instructions as well as the supported versions.

Config file bundles (zip) are generated on-the-fly (POST /api/config) and contain the user-specific config and our CA cert. The PKCS11 settings are automatically generated based on the platform and user eID chip number.

API security

Only the registration (/api/reg) is publicly accessible, everything else is shielded with user auth (no RBAC ATM).

The API server is SSL only, and is provided with a valid Gandi-issued certificate. The API sets CORS headers (currently wildcard).

Keystore generation:

 cat GandiStandardSSLCA.pem certificate.pem certificate.key > keypair_with_intermediate.pem # Gandi intermediate needs to be included in the cert chain for Firefox, otherwise it goes bananas saying "sec_unkown_issuer"

 openssl pkcs12 -export -in keypair_with_intermediate.pem -out server.p12 -name "vpn.neutrinet.be" # convert to PKCS12

 keytool -importkeystore -deststorepass <pwd> -destkeypass <pwd> -destkeystore neutrinet.keystore -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass <p12 export pwd> -alias vpn.neutrinet.be # import into keystore