|
|
Chris Stankaitis wrote: > Sunil S wrote: > >> See the man page >> --- quote-- >> --reneg-sec n >> Renegotiate data channel key after n seconds (default=3600). >> --- unquote >> >> > > --reneg-sec is definitely the option to use here, however keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side. > Thank you very much for bring this setting to my attention I will be > testing it right away. > > One question though. Does key renegotiation happen across the > established session like in ssh. If so then why would renegotiating the > key cause the pam-auth plug in to be re-invoked. I could see if > renegotiation ripped down the tunnel and basically started everything > from scratch, but if it occurs over the established session is there > really a need to re-auth the user when exchanging new keys? > > Thanks for you time on this matter. > OpenVPN uses different session constructs for SSL/TLS key state, and tunnel state. This is so that you can construct a long-term tunnel, but still have the underlying SSL/TLS session restart and renegotiate every hour. Consider this a feature -- you get the usability of a long-term tunnel, with the security of frequent rekeying of session keys. Now of course if those hourly renegotiations require end-user input as part of a two-factor approach, then it potentially becomes a hassle -- you might want to recalibrate the authentication interval with --reneg-sec. So when you ask "if it occurs over the established session is there really a need to re-auth the user when exchanging new keys?", the answer is yes, because the reneg-sec parameter tells OpenVPN the maximum allowable lifetime for an established SSL/TLS session before it expires. Now it's possible to have the OpenVPN client daemon cache passwords (this is the default, but can be disable with --auth-nocache), so that when the SSL/TLS renegotiation occurs, the client daemon can resubmit the cached password, rather than bothering the user to reenter it. However, if you are using dual-factor authentication, each --reneg-sec authorization interval may cause the end-user to be challenged to enter additional info above and beyond what OpenVPN caches. James ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |