On 02/16/2014 08:55 AM, Nikos Mavrogiannopoulos wrote: > On 02/16/2014 05:41 AM, Kevin Cernekee wrote: >> On Fri, Feb 14, 2014 at 11:51 PM, Nikos Mavrogiannopoulos >> <nmav at gnutls.org> wrote: >>> I noticed that this pattern is on several other logs posted before. So >>> it seems that anyconnect handle the rekey of the TLS channel and simply >>> reconnect the DTLS channel at the same moment (I see that there isn't >>> even a configuration option to change the rekey time of DTLS). >> >> When comparing your new rekey code to what is in the existing >> start_cstp_connection(), it occurred to me that we may be operating >> under different assumptions: >> In your experimentation with Cisco AnyConnect clients, do you see them >> sending a brand new DTLS master secret during rekey (ala commit >> 9d2b41dc8) or merely re-handshaking / re-establishing the DTLS session >> in order to generate new session keys? > > If I set the Rekey-Method to 'ssl' the process is: > 1. The CSTP channel performs a rehandshake > 2. The DTLS channel is disconnected, and reconnects (using the same key > - there is no way to negotiate a different key - but different nonces). > That is pretty much equivalent to a rehandshake. I've split my patch into three parts now: 6d855b1e6191a7e4e5d3e7026b75b1a1d0a5ffb7: Increases DTLS timeout to 12 secs a983aed4f5c12a1b08ab53c0369795b05106421b: Does SSL rehandshake when the "X-CSTP-Rekey-Method: ssl" header is seen (this is both for cisco servers and ocserv). 57bf2a46451c5e62ff42ab431d80aa82b88cd53d: Does DTLS rehandshake when the "X-DTLS-Rekey-Method: ssl" header is seen (ocserv only sends that). Otherwise do nothing. (Something similar with your patch https://github.com/cernekee/openconnect/commit/a53877ea22a546b12a9e2c30561fbd38c695532e is assumed, so that openconnect re-establishes the DTLS channel after a rehandshake on CSTP) git://gitorious.org/openconnect-x/openconnect-x.git rekey regards, Nikos
