Multifactor Authentication and Session Resumption in OpenVPN

Transcription

1 Multifactor Authentication and Session Resumption in OpenVPN Report submitted in accordance with the requirements of the Indian Institute of Technology, Kanpur by Harshvardhan Sharma (11299), Shivanshu Agrawal (11688), Srijan R. Shetty (11727) November 2014

2 Abstract OpenVPN is an open source implementation of a Virtual Private Network. 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 has been to research and provide a first class user experience to the end user when using MFA with OpenVPN; including the support for session resumption and backwards compatibility with older versions of OpenVPN. In the long run, the authors would want their implementation of the changes discussed below be merged with the upstream version of OpenVPN. The entire project is GNU GPL Licensed and the source code is available on GitHub[7] The authors also maintain a Wiki page which tracks progress and has more information on the project at MFA. i

3 Contents Abstract Contents Acknowledgement Nomenclature i iii iv iv OpenVPN Introduction Architecture Encryption Authentication Modes Key Methods Networking Protocol Multifactor Authentication Introduction Challenges Implementation Packet Structure MFA Plugin Types Authentication mechanism Backwards Compatibility Configuration Server Client Backwards Compatibility Release Notes Commit Log ii

4 Session Resumption Introduction Challenges Implementation Possible Approaches Session Tokens Configuration Server Client Commit Log A OpenVPN Protocol 11 B Multifactor Authentication 15 B.1 Commit Log C Session Resumption 16 C.1 Commit Log Bibliography 17 Index 17 iii

5 Acknowledgement The authors would like to thank Professor Dheeraj Sanghi for his continued guidance and support, Guillaume Destuynder of Mozilla who mentored the authors despite his hectic schedule and lastly Mozilla for giving the authors an opportunity to work on a project like OpenVPN under its aegis. The authors wish to thank the University of Liverpool Computing Services Department for the development of this L A TEX thesis template. iv

6 OpenVPN 1.1 Introduction A Virtual Private network allows two devices to securely communicate with each other over a possibly insecure public network. This concept when extended to networks allows for secure communications between different private networks over an insecure network (most often the internet), through tunnelling and there by allowing all these private networks to be virtually connected. OpenVPN 1 is a GNU General Public Licensed 2 implementation of a Virtual Private Network written in C maintained by the OpenVPN project. The source of OpenVPN is freely available for modification; thereby encouraging willing developers to contribute to the development of OpenVPN. The changes made, if accepted by the developer community are eventually merged with the upstream version of OpenVPN. 1.2 Architecture Encryption OpenVPN can use either of OpenSSL or PolarSSL for encryption and decryption. The choice of the SSL library can be provided during compilation of OpenVPN binary Authentication Modes OpenVPN provides for two authentication modes: 1. Static Key: In this mode, a key is generated and shared between the users before the establishment of a tunnel. The static key comprises of four independent keys: HMAC send, HMAC receive, encrypt key and decrypt key. 2. TLS: In this mode, a bidirectional session using certificates is established between. On a successful TLS/SSL authentication, both side exchange source material for the key which is used to generate eight different keys (for the client and server). The key generation depends on the key method provided. Key method 1 derives it s source material from OpenSSL RAND bytes while key method 2 derives it from TLS PRF[6] function. Refer to

7 1.2.3 Key Methods The current architecture of OpenVPN supports two key methods: 1. Key Method 1, the legacy key method only checks for the validity of certificates. Refer to Appendix A on page 11 for details. 2. Key Method 2, in addition to checking for the validity of certificates, allows for authentication of the user through username and password. The verification of username and password is delegated to either a script or a plugin which returns a binary result indicating a success or failure. Refer to Appendix A on page 11 for details Networking TLS/SSL protocol mandates a reliable transport layer, while on the other hand the tunnelled IP packets require a unreliable layer beneath them. To overcome this reliability-layer collision, Open- VPN multiplexes both these connections. The SSL/TLS session used for authentication and key exchange is still sent over UDP but with a reliability layer provided by OpenVPN. Multiplexed with SSL/TLS session are the IP packets, which after being encrypted and signed by and HMAC are directly passed over the UDP layer. This ensures that each of these channels gets what it expects from the layer beneath it. Additionally, both these channels are completely independent of each other and hence do not interfere with each other s functioning. SSL/TLS -> Reliability Layer -> \ --tls-auth HMAC \ \ > Multiplexer ----> UDP / Transport IP Encrypt and HMAC / Tunnel -> using OpenSSL EVP --> / Packets interface. Figure 1.1: OpenVPN Networking Note: In recent releases OpenVPN, support TCP as a transport layer as well. 1.3 Protocol OpenVPN uses a custom protocol[1] for communications which is attached in appendix A on page 11 for perusal. 2

8 Multifactor Authentication 2.1 Introduction Multifactor Authentication, henceforth used interchangeably with MFA, hardens access control by challenging a user on at least two out of the following three factors of authentication. 1. Knowledge Factor: The knowledge factor of authentication comprises of authentication methods which tests the user for the knowledge of a pre-shared secret. things only the user knows. For example: ATM Pins, website passwords. 2. Possession Factor: The possession factor of authentication comprises of authentication methods which tests the user for the possession of an entity. things only the user has. For example: Smart cards, ATM Cards. 3. Inherence Factor: The inherence factor of authentication comprises of authentication methods which tests the user for possession of things only the user is. For example: Retinal scans, Fingerprint scans. While conventional methods of authentication only take into account a knowledge factor, (most internet websites which a username password mechanism to authenticate users) multi factor authentication includes at least two different factors from the aforementioned list and might even have multiple authentication methods for a particular factor. 2.2 Challenges 1. Singled Threaded: OpenVPN is single threaded process with an event loop which allows it to handle concurrent connection requests. Every request fires a timer in OpenVPN and if authentication does not succeed before the time quantum expires, the connection is reset. The time-out being tried and tested, was not up for modification. Considering that current MFA schemes like OTP depend upon non-reliable mechanisms like SMS during which the timeout might expire, we made use of the plugin system of OpenVPN which allowed for deferred authentication. Hence overcoming the hurdle of time-out during authentication. (Refer to on page 6 for implementation details.) 3

9 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] 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) Figure 2.2: Old Plaintext packet structure 2. MFA Types: Multiple solutions are available for multifactor authentication, hence there was a need to provide an extensible mechanism to use the different available MFA authentication schemes. (Refer to on page 4 for implementation details.) 3. Backwards Compatibility: Considering that not all servers will want to support MFA, all the changes were introduced in a non breaking fashion. (Refer to on page 7 for implementation details.) 4. Defensive Coding: OpenVPN uses a defensive style of coding by using various abstractions for garbage collection, memory allocation to overcome the shortcomings of C and to protect against malicious users and untrusted input. 2.3 Implementation Packet Structure The packet structure of key method 2 - Refer to 2.3 on page 4 - was augmented with the addition of a MFA-username and a MFA-password in the options of TLS plaintext packet (key method 2) - Refer to on page 5 - following username and password fields for AUTH-USERPASS. To ensure backwards compatibility, all augmentations were made at the end of the packet MFA Plugin Types Three new OpenVPN plugin types have been introduced to support MFA. 4

10 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] 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). [The MFA data below is optional] mfa_username_string_length, including null (2 bytes). MFA Username string (n bytes, null terminated). mfa_password_string_length, including null (2 bytes) MFA Password string (n bytes, null terminated) Figure 2.3: New plaintext packet structure MFA types OPENVPN PLUGIN AUTH MFA OTP VERIFY A one time password - OTP 3 - consist of only a password which can be conveniently delivered to the user using SMS, an OTP-stick, or an application like Google Authenticator. OPENVPN PLUGIN AUTH MFA USER PASS VERIFY The conventional username-password scheme requires the user to provide both a username and password for multifactor authentication. OPENVPN PLUGIN AUTH MFA PUSH VERIFY No input is required by the user in a push message 4 except the confirmation of a push from a pre selected device. In case of OTP authentication, the username field is set to the Common Name of the user and the OTP is sent as the password. The Common Name is sent as the username in PUSH with an 3 OTPs are a suite of digits, usually 6 to 8 digits long, which work only once and are invalidated after use (HOTP[3]) or valid for a certain period of time (TOTP[5]) 4 A push message is a push notification to a device owned by the user. On accepting the push message, the device sends the response to the server which in turn relays it to the OpenVPN plugin 5

11 empty string as password. The username and password fields are populated with the user supplied values in case of USER-PASS. To allow for maximum extensibility of MFA, the actual implementation of each kind of of MFA is left to the plugin/script writer to prevent a vendor lock down Authentication mechanism At the time of booting, the plugin/script mentioned in the configuration file is registered by Open- VPN s plugin system (only one plugin/script is allowed). During authentication, OpenVPN simply calls the registered plugin/script waits for a success/failure response. On receiving a success, Open- VPN continues on with the rest of the protocol; and on receiving a failure, OpenVPN immediately terminates the client connection by sending the client a SIGTERM signal Backwards Compatibility The following scenarios have been addressed under the backwards compatibility flag: Compatibility Server Client Action New Client, MFA-Enabled MFA-auth Enabled New Server, MFA-enabled New Client, MFA-Disabled auth-failure Old Client old-auth Disabled New Server, MFA-enabled Old Client auth-failure * New Server, MFA-disabled New Client, MFA-Enabled MFA-auth New Client, MFA-disabled old-auth * New Server, MFA-disabled Old Client old-auth * Old Server New Client, MFA-Enabled MFA-auth New Client, MFA-Disabled MFA-auth 2.4 Configuration Server To enable multifactor authentication in the server using a script, the following line needs to be included in the configuration file of the server: mfa-method [method-type] [script file name] [via-env/via-file] Here method-type is one of otp, push or user-pass. For example: mfa-method otp auth.pl via-file Multifactor authentication can also be enabled using plugins, the incantation for the same is: 6

12 mfa-method [method-type] plugin [plugin shared object file] Client To enable multifactor authentication in the client, the following line needs to be included in the configuration file of the client: mfa-method [method-type] Backwards Compatibility The server can allow connections from old clients during the initial transition phase by adding the following line to its configuration file: mfa-backward-compat 2.5 Release Notes 1. OpenVPN should be compiled with the enable-mfa (enabled by default) flag for Multifactor Authentication support. 2. The changes introduced by Multifactor Authentication despite being a complete overhaul of key method 2 constitute only a minor patch according to the Semver specification Commit Log Refer to Appendix B on page 15 for the commit log. 5 Semver or Semantic Versioning is a system of naming software releases as MAJOR.MINOR.PATCH. A major change introduces breaking changes to software. A minor change introduces non breaking features to software. A patch introduces non breaking fixes to the software. 7

13 Session Resumption 3.1 Introduction Multifactor Authentication trades security for convenience. While addition factors of authentication reduces the probability of the impersonation of user even in the face of the loss of password, they increase the complexity of authentication and ergo lead to a bad user experience. To provide a smoother user experience, most web based multifactor authentication flows provide for session resumption. Session resumption allows devices which on which the user has authenticated once using multifactor authentication to transparently store an additional secret the session token between the client and the server. The session token expires after a certain period of time, and provides for the additional factor of authentication without taking recourse to MFA. 3.2 Challenges 1. Security: The session resumption mechanism should be secure and resilient against cryptographic and implementation-based attacks. The session token used should be tied to the client s identity and it should not be possible for any entity other than the server to generate a valid token for any client within a reasonable amount of time. 2. User Experience: The entire process should be transparent to the user. Enabling support for session resumption should require minimal changes to the client and server configuration files. 3. Protocol: The entire procedure of session resumption should fit into the existing OpenVPN protocol so as to maintain backwards compatibility. 3.3 Implementation Possible Approaches There were two possible approaches to implement session resumption: TLS session resumption without server side state[4] or session cookies. We chose the latter for the following reasons: 1. It is widely recognized that TLS Session Resumption is not secure and many theoretical attack 8

14 vectors[8] have been proposed which leverage not the implementation of the feature but the fundamental ideas backing TLS Session Resmption. 2. The community norm seems to favour using only widely deployed features of TLS and not proposed features; and session resumption happens to be not used widely. 3. Session Resumption through cookies is widely used on many websites to maintain login sessions. In the case of OpenVPN, cookies are encrypted before being transferred which provides extra security and prevents session hijacking Session Tokens The chosen method of session resumption makes use of session tickets/tokens which are provided by the server to the client on successful authentication and can be used in future sessions to bypass the authentication. The session token is analogous to cookies used by websites to maintain state. On startup, the server generates a key (48 bytes). When the client successfully authenticates with MFA credentials, the server generates a token which is the HMAC [2] of the client s Common Name and the current UNIX timestamp using the key. The HMAC is calculated by XORing HMAC-SHA1 and HMAC-MD5. This procedure is also used by OpenVPN during tunnel key negotiation. The token and timestamp are sent back to the client in the server s key method 2 packet (See Fig ). The client stores these in a local file. During next authentication the timestamp and the token are sent instead of the MFA credentials. The server verifies that the timestamp is within mfa-session-expiration (Section 3.4) hours and verifies its authenticity by generating the HMAC and comparing it against the received token. If the verification succeeds, authentication is considered successful. If not, the client is prompted for the credentials. The advantage of this approach is that the server does not need to store any information related to the session. Hence no additional file or database is required to add session support. 3.4 Configuration Session Resumption, builds upon Multifactor Authentication, hence configuration parameters of MFA need to be setup for any of the following configuration parameters to have effect Server To enable session resumption in the server, a token expiration time must be provided in the server configuration file. 9

15 Credentials < SESSION 1 Server Client > Session token Session SESSION 2 token Server < Client Figure 3.4: Session resumption mfa-session-expiration [session-validity (in hours)] Client To enable multifactor authentication in the client, a file to store session tokens must be provided in the client configuration file. mfa-session-file [filename] In the absence the above configuration parameter, the user is warned and session resumption is disabled. 3.5 Commit Log Refer to Appendix C on page 16 for the commit log. 10

16 Appendix A OpenVPN Protocol [1] / OpenVPN Protocol, taken from s s l. h in OpenVPN source code. TCP/UDP Packet : This r e p r e s e n t s the top l e v e l e n c a p s u l a t i o n. TCP/UDP packet format : Packet l e n g t h (16 b i t s, unsigned ) TCP only, always sent as p l a i n t e x t. Since TCP i s a stream protocol, the packet l e n g t h words d e f i n e the p a c k e t i z a t i o n o f the stream. Packet opcode / k e y i d (8 b i t s ) TLS only, not used in pre shared s e c r e t mode. packet message type, a P constant ( high 5 b i t s ) k e y i d ( low 3 b i t s, s e e k e y i d in s t r u c t t l s s e s s i o n below f o r comment ). The k e y i d r e f e r s to an a l r e a d y n e g o t i a t e d TLS s e s s i o n. OpenVPN s e a m l e s s l y r e n e g o t i a t e s the TLS s e s s i o n by using a new k e y i d f o r the new s e s s i o n. Overlap ( c o n t r o l l e d by user d e f i n a b l e parameters ) between old and new TLS s e s s i o n s i s allowed, p r o v iding a seamless t r a n s i t i o n during tunnel o p e r a t i o n. Payload ( n bytes ), which may be a P CONTROL, P ACK, or P DATA message. Message types : P CONTROL HARD RESET CLIENT V1 Key method 1, i n i t i a l key from c l i e n t, f o r g e t p r e v i o u s s t a t e. P CONTROL HARD RESET SERVER V1 Key method 1, i n i t i a l key from s e r v e r, f o r g e t p r e v i o u s s t a t e. 11

17 P CONTROL SOFT RESET V1 New key, with a g r a c e f u l t r a n s i t i o n from old to new key in the s e n s e that a t r a n s i t i o n window e x i s t s where both the old or new k e y i d can be used. OpenVPN uses two d i f f e r e n t forms o f k e y i d. The f i r s t form i s 64 b i t s and i s used f o r a l l P CONTROL messages. P DATA messages on the other hand use a shortened k e y i d o f 3 b i t s f o r e f f i c i e n c y r e a s o n s s i n c e the vast majority o f OpenVPN packets in an a c t i v e tunnel w i l l be P DATA messages. The 64 b i t form i s r e f e r r e d to as a s e s s i o n i d, while the 3 b i t form i s r e f e r r e d to as a k e y i d. P CONTROL V1 Control channel packet ( u s u a l l y TLS c i p h e r t e x t ). P ACK V1 Acknowledgement f o r P CONTROL packets r e c e i v e d. P DATA V1 Data channel packet c o n t a i n i n g a c t u a l tunnel data c i p h e r t e x t. P CONTROL HARD RESET CLIENT V2 Key method 2, i n i t i a l key from c l i e n t, f o r g e t p r e v i o u s s t a t e. P CONTROL HARD RESET SERVER V2 Key method 2, i n i t i a l key from s erver, f o r g e t p r e v i o u s s t a t e. P CONTROL and P ACK Payload : The P CONTROL message type i n d i c a t e s a TLS c i p h e r t e x t packet which has been encapsulated i n s i d e o f a r e l i a b i l i t y l a y e r. The r e l i a b i l i t y l a y e r i s implemented as a s t r a i g h t f o r w a r d ACK and r e t r a n s m i t model. P CONTROL message format : l o c a l s e s s i o n i d ( random 64 b i t value to i d e n t i f y TLS s e s s i o n ). HMAC s i g n a t u r e o f e n t i r e e n c a p s u l a t i o n header f o r i n t e g r i t y check i f t l s auth i s s p e c i f i e d ( u s u a l l y 16 or 20 bytes ). packet id f o r r e p l a y p r o t e c t i o n (4 or 8 bytes, i n c l u d e s sequence number and o p t i o n a l t i m e t timestamp ). P ACK p a c k e t i d array l ength (1 byte ). P ACK packet id array ( i f l ength > 0 ). P ACK remote s e s s i o n i d ( i f length > 0 ). message packet id (4 bytes ). TLS payload c i p h e r t e x t ( n bytes ) ( only f o r P CONTROL). Once the TLS s e s s i o n has been i n i t i a l i z e d and authenticated, the TLS channel i s used to exchange random key m a t e r i a l f o r b i d i r e c t i o n a l c i p h e r and HMAC keys which w i l l be used to s e c u r e a c t u a l tunnel packets. OpenVPN c u r r e n t l y implements two key methods. Key method 1 d i r e c t l y 12

18 d e r i v e s keys using random b i t s obtained from the RAND bytes OpenSSL f u n c t i o n. Key method 2 mixes random key m a t e r i a l from both s i d e s o f the connection using the TLS PRF mixing f u n c t i o n. Key method 2 i s the p r e f e r r e d method and i s the d e f a u l t f o r OpenVPN TLS p l a i n t e x t content : TLS p l a i n t e x t packet ( i f key method == 1 ) : Cipher key l e n g t h in bytes (1 byte ). Cipher key ( n bytes ). HMAC key l e n g t h in bytes (1 byte ). HMAC key ( n bytes ). Options s t r i n g ( n bytes, n u l l terminated, c l i e n t / s e r v e r o p t i o n s s t r i n g should match ). TLS p l a i n t e x t packet ( i f key method == 2 ) : L i t e r a l 0 (4 bytes ). key method type ( 1 byte ). k e y s o u r c e s t r u c t u r e ( pre master only d e f i n e d f o r c l i e n t > s e r v e r ). o p t i o n s s t r i n g l e n g t h, i n c l u d i n g n u l l (2 bytes ). Options s t r i n g ( n bytes, n u l l terminated, c l i e n t / s e r v e r o p t i o n s s t r i n g must match ). [ The username / password data below i s optional, record can end at t h i s point. ] u s e r n a m e s t r i n g l e n g t h, i n c l u d i n g n u l l (2 bytes ). Username s t r i n g ( n bytes, n u l l terminated ). p a s s w o r d s t r i n g l e n g t h, i n c l u d i n g n u l l (2 bytes ). Password s t r i n g ( n bytes, n u l l terminated ). The P DATA payload r e p r e s e n t s encrypted, encapsulated tunnel packets which tend to be e i t h e r IP packets or Ethernet frames. This i s e s s e n t i a l l y the payload o f the VPN. P DATA message content : HMAC o f c i p h e r t e x t IV + c i p h e r t e x t ( i f not d i s a b l e d by auth none ). Ciphertext IV ( s i z e i s cipher dependent, i f not d i s a b l e d by no i v ). Tunnel packet c i p h e r t e x t. P DATA p l a i n t e x t p a c k e t i d (4 or 8 bytes, i f not d i s a b l e d by no r e p l a y ). In SSL/TLS mode, 4 bytes are used because the implementation can f o r c e a TLS r e n e g o t a t i o n b e f o r e 2ˆ32 packets are sent. 13

19 In pre shared key mode, 8 bytes are used ( sequence number and t i m e t value ) to allow long term key usage without p a c k e t i d c o l l i s i o n s. User p l a i n t e x t ( n bytes ). Notes : ( 1 ) ACK messages can be encoded in e i t h e r the dedicated P ACK r e cord or they can be prepended to a P CONTROL message. ( 2 ) P DATA and P CONTROL/P ACK use independent packet id sequences because P DATA i s an u n r e l i a b l e channel while P CONTROL/P ACK i s a r e l i a b l e channel. Each use t h e i r own independent HMAC keys. ( 3 ) Note that when t l s auth i s used, a l l message types are p r o t e c t e d with an HMAC s i g n a t u r e, even the i n i t i a l packets o f the TLS handshake. This makes i t easy f o r OpenVPN to throw away bogus packets quickly, without wasting r e s o u r c e s on attempting a TLS handshake which w i l l u l t i m a t e l y f a i l. / 14

20 Appendix B Multifactor Authentication B.1 Commit Log Taken form (Wed Oct 29) bc05baa c l e a r MFA c r e d e n t i a l s in s s l p u r g e a u t h ( Sun Oct 19) c misc f i x e s (Tue Oct 14) 95 f f 0 b 5 Backward c o m p a t i b i l i t y f o r MFA a u t h e n t i c a t i o n (Wed Oct 15) e0bfc77 s /MAX MFA METHODS/MFA TYPE N, send mfa type as i n t (Thu Oct 9) d8 minor cleanup (Thu Oct 9) r e f a c t o r mfa o p t i o n s (Wed Oct 8) 53 d7aec p a s s i n g c r e d e n t i a l s to s c r i p t via f i l e (Wed Oct 1) 6 f298d5 auth by s c r i p t (Wed Oct 1) 397 b7f4 r e f a c t o r e d m f a m e t h o d s l i s t ( Sat Sep 2 7) 504 b0e9 Removed MFA name parameter (Thu Sep 25) 83 c 0 f 4 5 r e s t r i c t the maximum number o f mfa methods to 8 (Wed Sep 24) 1baab9b v e r i f i e d the MFA c r e d e n t i a l s via plugin (Tue Sep 9) 985 d7d1 read and v e r i f y MFA o p t i o n s ( Sun Sep 7) 769 c841 w r i t e MFA o p t i o n s in key method 2 packet ( Fri Sep 5) f10bd46 check mfa type while reading c o n f i g f i l e ( Fri Sep 5) e Get MFA c r e d e n t i a l s from user (Mon Sep 1) 01 dcf59 read MFA o p t i o n s from c o n f i g f i l e 15

21 Appendix C Session Resumption C.1 Commit Log Taken form ( Sat Nov 8) 8995 c27 hard coded key and c o o k i e f o r CN c l i e n t 2 ( Sat Nov 8) db1c1f4 f i x e s in v e r i f y c o o k i e ( ) ( Sat Nov 8) c c f c don t goto e r r o r i f c o o k i e v e r i f i c a t i o n succeeds ( Fri Nov 7) e f c f c l i e n t s i d e f i x e s f o r s e s s i o n support ( Fri Nov 7) ec58441 f i x e s ; token g e n e r a t i o n working ( Fri Nov 7) 4734 d94 use hours f o r mfa s e s s i o n v a l i d i t y ( Fri Nov 7) b46ed78 Bug f i x : auth mfa setup i s now c a l l e d p r o p e r l y everywhere ( Fri Nov 7) b81684d Fix f o r g c f r e e and t v w i t h i n m i n u t e s (Wed Nov 5) e60debd Check f o r c o o k i e e x p i r a t i o n (Wed Nov 5) b32e6b7 Fix f o r m f a s e s s i o n t o k e n s e n t (Wed Nov 5) 2 a668d8 c r e a t e new c o o k i e in key method 2 write (Wed Nov 5) 1 a31f12 f i x e s (Wed Nov 5) 3 a36fb8 v e r i f y and g e nerate f u n c t i o n s f o r checking c o o k i e (Tue Nov 4) 79 d9279 f i x e d a6cfa86 (Tue Nov 4) a6cfa86 WIP: changes in key method 2 read on s e r v e r s i d e (Mon Nov 3) 02 d242f WIP: read c l i e n t c o o k i e from key method 2 packet (Mon Nov 3) c8c1837 WIP: Cookie c r e a t i o n by s e r v e r ; TODO: c r e a t e c o o k i e ( ) (Mon Nov 3) 03 bb698 Fixes f o r p r e v i o u s compilation e r r o r s ( Sun Nov 2) bbf6fad Changed the d i r e c t i v e f o r mfa s e s s i o n ( Sun Nov 2) bade0e4 WIP: Read c l i e n t sent data ( Sat Nov 1) d7a5e2f WIP: Functions f o r p a r s i n g timestamp ( Sat Nov 1) e00da6c SQUASH: Fixes f o r p r e v i o u s commit ( Fri Oct 31) e 5 e f g e n e r a t e IV when s e r v e r s t a r t s up ( Fri Oct 31) b10b95d f i x compiler e r r o r s (Thu Oct 30) 50 f8189 WIP, w r i t e s e s s i o n token in key method 2 packet (Wed Oct 29) e6 WIP: s e s s i o n support (Wed Oct 29) d60887c Module f o r mfa s e s s i o n (Tue Oct 28) 064 a895 Read mfa s e s s i o n o p t i o n s ( Sun Oct 19) c misc f i x e s 16

22 Bibliography [1] OpenVPN Community. Openvpn security overview. Accessed: [2] Internet Engineering Task Force. Hmac: Keyed-hashing for message authentication. Accessed: [3] Internet Engineering Task Force. Hotp: A hmac based one-time password algorithm. Accessed: [4] Internet Engineering Task Force. Tls session resumption without server-side state. Accessed: [5] Internet Engineering Task Force. Totp: Time based one-time password algorithm. Accessed: [6] Internet Engineering Task Force. Transport layer security (tls) protocol v Accessed: [7] Srijan R. Shetty Harshwardhan Sharma, Shivanshu Agarwal. Source code repository. Accessed: [8] Secure Resumption. Triple handshakes considered harmful breaking and fixing authentication over tls. Accessed: