Security/Mentorships/MWoS/2014/OpenVPN MFA

Team

Introduction

We are a team of three Senior Undergraduates at Indian Institute of Technology, Kanpur, majoring in Computer Science and Engineering. We have eclectic interests but most of them are in Systems and InfoSec. (We were formally initiated in InfoSec only last semester). Shivanshu worked in GSoC, Harsh worked with Directi and Srijan interned at Microsoft Research India over the summers; so we've got some code crunching skills up our sleeves as well :D

Members

Shivanshu Agrawal
Srijan Shetty
Harshvardhan Sharma
Professor: Dr. Dheeraj Sanghi
Mozilla Advisor: Guillaume Destuynder

Project

Mozilla uses OpenVPN with MFA via deferred C plugins and pythons scripts. However, there are several caveats that require non-plugin based modifications, such as One Time Passwords (OTP) client input and session tracking. The goal of this project is to research and provide a first class user experience when using MFA with OpenVPN, and contribute it to the Open Source OpenVPN project.

Description

This project aims to add support for:

User session id and tracking
True multi-factor authentication support

Scope

This project only includes the official OpenVPN command line server and client. Support for 3rd party clients is out of the scope.

Success Criteria

Ability to log in with a 2nd factor to OpenVPN, lose the connection, reconnect with the session id and without getting a 2nd factor authentication prompt for a determined period of time. In a nutshell, have a similar experience to web-based MFA solutions.

Updates

We have a weekly meeting every wednesday, at 9AM PDT (9:30 IST).

<date>

current work
blocking points
discussion points
upcoming work

2014-09-14

TODO

Backwards Compatibility

Method

We've dropped the initial plan of introducing a new key method 3 in favour of modifying key-method-2 with added MFA support under the compile flag ENABLE_MFA (enabled by default). This decision comes in light of the complexity of creating a new key-method and considering the fact that the new key-method had large chunks of code taken from key-method-2 as is.

Protocol

Configuration

Progress

Instead of working on a POC program, we've started working on implementing MFA support in OpenVPN.
Compiler flag ENABLE_MFA has been implemented.
mfa parameters are read from server and client configuration.
sanity check of parameters configuration files has been implemented.
credentials for MFA have been acquired from client.
key_method_2_read and key_method_2_write have been modified to include MFA options.

2014-08-14

Current work
We have looked at the OpenVPN code that handles authentication. The authentication is two step. In the first step, a TLS connection is set up using the certificates. After this, the tunnel is set up for which new keys are generated. If key method 2 is used, username/password can be used for authentication while setting up the tunnel. Contents of authentication packet

* TLS plaintext packet (if key_method == 2):
*   Literal 0 (4 bytes).
*   key_method type (1 byte).
*   key_source structure (pre_master only defined for client ->
*       server).
*   options_string_length, including null (2 bytes).
*   Options string (n bytes, null terminated, client/server options
*       string must match).
*   [The username/password data below is optional, record can end
*       at this point.]
*   username_string_length, including null (2 bytes).
*   Username string (n bytes, null terminated).
*   password_string_length, including null (2 bytes).
*   Password string (n bytes, null terminated).
Reference: http://openvpn.net/index.php/open-source/documentation/security-overview.html

Username/password is passed to plugin/external script for verification and not handled by OpenVPN.
Proposed solution
We could use a new key method (key method 3) for MFA with a packet structure similar to that of key method 2. Options field can be used to specify the supported authentication methods. There can be an optional session identifier field for resuming sessions.

It would be convenient if we implement MFA before session support.

Discussion points

How secure are the proposed solutions?
Should MFA be mandatory for all clients or should it be opt-in?
OpenVPN doesn't use any database for persistent storage. It uses text files. (OpenVPN Access server uses sqlite3). Should we use files or sqlite for server side storage?
What if the server and client use different key methods?
Backward compatibility(if the server and client run different versions of openvpn?)

Upcoming work

Make a PoC program implementing session support.

2014-08-10

Task

1) Implement session support in openvpn 2) Implement MultiFactor Authentication in openVpn

Session Support

When a client connects, after the TLS session is established (handshake done): Server requests a list of authentication methods ( generally it'll be Certificate + OTP or Push). Authentication methods can be - Certificate + OTP/Push, The session id method is special and is the only optional method when it fails, auth fails and the client is asked to renegociate, this time, the server doesnt ask for a session id.. AND the client must present its ability to use a session id before the server presents the authentication methods

Session Resumption Alternatives

(inspired by TLS http://tools.ietf.org/html/rfc5077 and http://tools.ietf.org/html/rfc5246 )

Option 1

Store the session state on the server and an identifier on client side. When the client connects to the server and the client does not provide a session ticket , the server generates the ticket according to the following specifications.

The session state contains

the CN of the client
timestamp / expiry time
OpenVPN session ID
any other required fields

Generate a random key name (32 bits) and a random key (128 bits). Generate the HMAC-SHA of the session state appended with the key. Send the HMAC and key name to the client. Store the key name, key and session state in the server-side database.

When client requests a session resumption by sending the key name and the HMAC, the server looks up the session state and key using the key name, verifies the HMAC and the session state. Verification of session state involves checking the CN of the client and the expiration of the session (To avoid computing the HMAC on every request, we may cache the HMACs in the server database)

Option 2

Only client stores the session information

When the client connects to the server and the client does not provide a session ticket , the server generates the ticket according to the following specifications.