Different auth criteria for renegotiating connections

mlasevich

I have an OpenVPN server using both certs AND username/password with 2-factor auth (pin+OTP code)

This works fine, except for key renegotiating. When renegotiating happens, users are forced to re-enter username/password, effectively forcing everyone to re-login every hour (using default reneg timeout). Without OTP I suspect OpenVPN remembers the password, but with OTP that password is no longer valid by time renegotiation happens. While I can change the renegotiation timeout, this does not solve the underlying issue and making rekey time too long definitely affects security.

I was wondering if renegotiation is supposed to re-authenticate user from scratch and if so, is it possible to use different criteria for initial key negotiation and for renegotiating - so that as long as your original key is still valid, you are not prompted for username/password (can still validate certs, etc)?

Thanks,

mwandelaar

Key renegotiation essentially means agreeing on a new session-key. To do this both parties needs to be sure the other-end is the real other party and not some mallory trying to impersonate the party.
The only way to do this, is using the "secret" from the other end. When you have a "running" openvpn-session, it does not matter anymore which way of authentication is used. This comes back to you when you need to renegotiate.
When you are using certificates, the private-key is accessed to do this. When openvpn is not caching passwords, you will be asked for the private-key password.
Renegotiating client's using 2-factor-authentication requires the server to revalidate the client and therefore it's "secret" is needed and the client is asked for a new OTP.

I can image this is annoying for the user. You could try to increase the renegotiation-time to something acceptable period, like 4 hours:

reneg-sec 14400

but take care of the other crypto-settings, as longer session-keys may have other security issues, depending on your situation.

Probably you are allready using different client-configs for 2-factor and certs, so you might consider to use different openvpn-daemons to finetune for both setups.

mlasevich

I understand that, but I am not sure I agree that it is the "only" way to do this. For one, I know of several major commercial VPN clients that do not work that way (Cisco , for one).

Overall, unlike the initial authentication, when you renegotiate you have one more shared secret - the previous session key. Traditionally, it is my understanding that re-keying uses the previous session key. Most cryptography is based on the idea that it takes too long to break the key. The reason we renegotiate they keys is to prevent someone breaking the key in the timespan the key is active - and thus being able to eavesdrop or take over a session. If someone is capable of breaking the session key in the lifespan of the session, the whole vpn game is over. Extending the session key lifetime greatly increases this risk. On the other hand, if we assume that the session is not broken during key key lifetime, using the previous session-key to negotiate new one, especially when combined with other shared secrets like certs, seems like a reasonably safe choice.

In the absence of support for traditional re-keying, I was wondering if it was possible to set a different authentication method (just cert+password or cert alone instead of cert+password+OTP)

-M

mwandelaar wroteKey renegotiation essentially means agreeing on a new session-key. To do this both parties needs to be sure the other-end is the real other party and not some mallory trying to impersonate the party.
The only way to do this, is using the "secret" from the other end. When you have a "running" openvpn-session, it does not matter anymore which way of authentication is used. This comes back to you when you need to renegotiate.
When you are using certificates, the private-key is accessed to do this. When openvpn is not caching passwords, you will be asked for the private-key password.
Renegotiating client's using 2-factor-authentication requires the server to revalidate the client and therefore it's "secret" is needed and the client is asked for a new OTP.

I can image this is annoying for the user. You could try to increase the renegotiation-time to something acceptable period, like 4 hours:
reneg-sec 14400
but take care of the other crypto-settings, as longer session-keys may have other security issues, depending on your situation.

Probably you are allready using different client-configs for 2-factor and certs, so you might consider to use different openvpn-daemons to finetune for both setups.

mwandelaar

Overall, unlike the initial authentication, when you renegotiate you have one more shared secret - the previous session key. Traditionally, it is my understanding that re-keying uses the previous session key. Most cryptography is based on the idea that it takes too long to break the key. The reason we renegotiate they keys is to prevent someone breaking the key in the timespan the key is active - and thus being able to eavesdrop or take over a session. If someone is capable of breaking the session key in the lifespan of the session, the whole vpn game is over. Extending the session key lifetime greatly increases this risk. On the other hand, if we assume that the session is not broken during key key lifetime, using the previous session-key to negotiate new one, especially when combined with other shared secrets like certs, seems like a reasonably safe choice.

I might as wel be wrong, but if i take the previoous session-key as a secret AND someone is capable of breaking the session-key, he is also able to read the negotiation of the new session-key, as he allready knows the "secret".
Therefore it would make no sense to rekey in any way, because having the first sessionkey, you can read along the entire communication. And therefor SSL shouldn't have any forward secrecy.
The only thing not known to the attacker is the private key. Therefor a sessionkey is a security for a short timespan: If someone is capable to break that one, he can only read along until the next rekeying.
I don't know how Cisco solves this fundamental issue, but they need to rekey too to guarantee forward secrecy.

petiepooo

I believe the way most other VPNs renegotiate their key is to perform a Diffie-Hellman exchange over the expiring tunnel to create a new shared secret to be used as the next session key. That solves the problem mwandelaar pointed out where using the previous session key to derive the next one negates any benefits of renegotiation, as DH allows secret creation even with eavesdropping. Authorization and authentication were already performed in setting up the session, so shouldn't need revalidating of the DH exchange uses it, although a follow-on check of the CRL would make sense then.

mlasevich

petiepooo wroteI believe the way most other VPNs renegotiate their key is to perform a Diffie-Hellman exchange over the expiring tunnel to create a new shared secret to be used as the next session key. That solves the problem mwandelaar pointed out where using the previous session key to derive the next one negates any benefits of renegotiation, as DH allows secret creation even with eavesdropping. Authorization and authentication were already performed in setting up the session, so shouldn't need revalidating of the DH exchange uses it, although a follow-on check of the CRL would make sense then.

Makes sense. Although I was under impression that usually authentication is handled separately from encryption/key exchange. Cisco did some funky things, even being able to re-establish a connection suspended for hours in some cases, while still requiring 2-factor for initial connections. I would be happy with simply having two levels of auth configured for the connection, 2-factor for initial connection, and then single factor for subsequent renegotiations. Similar things are done with other services based on source of the connection (2-factor from outside, 1 factor from inside) . As I already require users to have certs+pins+OTP, a renegotiation could simply drop to certs+pins (or even down to just certs) as long as the initial connection requires 2-factor and subsequent renegotiation happens while initial connection is still valid.

For now I just extended rekey time as it seems to be the only solution that works with OpenVPN without resorting to PAM hacking.