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 include 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).

2014-07-30

Kick off meeting.

• Work etherpad https://etherpad.mozilla.org/FoY0TOSa5k

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.

The session state contains

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

The session ticket contains the following fields

• key_name[16];
• iv[16];
• encrypted session state
• mac[32];

from RFC5077 -

Here, key_name serves to identify a particular set of keys used to
protect the ticket.  It enables the server to easily recognize
tickets it has issued.  The key_name should be randomly generated to
avoid collisions between servers.  One possibility is to generate new
random keys and key_name every time the server is started.

The actual state information in encrypted_state is encrypted using
128-bit AES in CBC mode with the given IV.  The Message
Authentication Code (MAC) is calculated using HMAC-SHA-256 over
key_name (16 octets) and IV (16 octets), followed by the length of
the encrypted_state field (2 octets) and its contents (variable
length).

2014-08-14

Current work
We have looked at the OpenVPN code that handles authentication. OpenVPN uses a modified version of TLS handshake. If key method 2 is used username/password are used for authentication during TLS handshake itself. 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. ??? Can this be dictated by the client ??? It would be convenient if we implement MFA before session support.

Discussion points

• 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.

<date>

• current work
• blocking points
• discussion points
• upcoming work