11
edits
Security/Mentorships/MWoS/2014/OpenVPN MFA: Difference between revisions
Security/Mentorships/MWoS/2014/OpenVPN MFA (view source)
Revision as of 11:47, 14 August 2014
, 14 August 2014Session Resumption
Srijanshetty (talk | contribs) m (→Members) |
Srijanshetty (talk | contribs) (Session Resumption) |
||
| Line 34: | Line 34: | ||
Kick off meeting. | Kick off meeting. | ||
* Work etherpad https://etherpad.mozilla.org/FoY0TOSa5k | * Work etherpad https://etherpad.mozilla.org/FoY0TOSa5k | ||
=== 2014-08-14 === | |||
==== 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 request 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 | |||
* 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 | |||
* any other required fields | |||
The session ticket contains the following fields | |||
* key_name[16]; | |||
* iv[16]; | |||
* encrypted session state | |||
* mac[32]; | |||
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)." - taken from RFC5077 | |||
=== <date> === | === <date> === | ||