[PULL request] distinguish between different rekey methods

[Nikos Mavrogiannopoulos]

On 02/14/2014 11:24 AM, David Woodhouse wrote:
> On Thu, 2014-02-13 at 22:53 -0800, Kevin Cernekee wrote:
>> If I set method "ssl" or "new-tunnel", the result is the same:
> 
>> X-CSTP-Rekey-Method: new-tunnel
>> X-DTLS-Rekey-Time: 240
>>
>> This could be a bug, or maybe it means the "ssl" method isn't
>> implemented on this firmware version.
> 
> Perhaps the SSL renegotiation method got deprecated around the time of
> CVE-2009-3555.

CVE-2009-3555 is unrelated to renegotiation as used in anyconnect. The
issue with renegotiation was when combined with https as a method of
"upgrading" credentials through renegotiation (e.g., provide your client
certificate only at a specific url through renegotiation).

It seems that (at least some of) the anyconnect clients when they
encounter the 'ssl' variant, they do renegotiate on the tcp channel, and
for some reason tear and reconnect the DTLS channel (they could have had
issues renegotiating the DTLS session the way they establish it).

ocserv could handle that mode as well as it considers the TCP channel
the primary. That way we could support a channel that doesn't
re-establish itself at rekey time. However, I find the tearing apart and
re-establishment of the DTLS channel a waste. Would it make sense to
have a mode 'oc-ssl' that will rehandshake on both channels?

regards,
Nikos