[PULL request] distinguish between different rekey methods

[Nikos Mavrogiannopoulos]

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