[PULL request] distinguish between different rekey methods

[Kevin Cernekee]

On Wed, Feb 12, 2014 at 2:10 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Tue, Feb 11, 2014 at 11:06 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>>> According to their documentation it performs a rehandshake over the
>>> session. That has to be verified with a cisco server though.
>>> For openconnect to support that (and test it), calling
>>> gnutls_handshake() over an existing session would be sufficient.
>> I have a *very* vague recollection of having tried that, and it not
>> being sufficient. It's been a long time though. And it might only have
>> been DTLS which stopped working; that required a rekey after 24 hours.
>> Which made it very painful to test, of course.
>
> It could be that anyconnect servers use a custom protocol to negotiate
> the rehandshake. For example it could be something like a packet
> 'start rehandshake' and then start the actual TLS rehandshake, but I
> find it highly unlikely as it is pointless. I have modified the rekey
> branch to handle redhandshakes, so I'd appreciate if somebody could
> test it against a cisco server.
>
> As I understand one would need to set something like
> svc rekey method ssl
> svc rekey time 1

On my ASA running 8.4, the syntax is a little different:

group-policy default attributes
 webvpn
  anyconnect ssl rekey time 4
  anyconnect ssl rekey method ssl

The allowed range is 4..10080 minutes.

If I set method "ssl" or "new-tunnel", the result is the same:

X-CSTP-Rekey-Time: 240
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.

If I set method "none", all of the above headers disappear.

FWIW, I still need this patch to prevent DTLS from going out to lunch
after CSTP reconnections:

https://github.com/cernekee/openconnect/commit/a53877ea22a546b12a9e2c30561fbd38c695532e

Every time I reconnect CSTP, I receive a new DTLS session ID from the ASA.