With OpenSSL commit 929b0d70c19f60227f89fac63f22a21f21950823 setting an empty
key fails if no previous key has been set on that HMAC.
In 9138f49e we explicitly added the check we remove now, as HMAC_Update()
might crash if HMAC_Init_ex() has not been called yet. To avoid that, we
set and check a flag locally to let any get_mac() call fail if set_key() has
not yet been called.
sem_init() is deprecated on OS X, and it actually fails with ENOSYS. Using our
wrapped semaphore object is not an option, as it relies on the thread cleanup
that we can't rely on at this stage.
It is unclear why startup synchronization is required, as we can allocate the
thread ID just before creating the pthread. There is a chance that we allocate
a thread ID for a thread that fails to create, but the risk and consequences
are negligible.
This is needed to fix usage stats sent via RADIUS Accounting if clients
use MOBIKE or e.g. the kernel notifies us about a changed NAT mapping.
The upper layers won't expect the stats to get reset if only the IPs have
changed (and some kernel interface might actually allow such updates
without reset).
It also fixes traffic based lifetimes in such situations.
Fixes#799.
This is needed to handle DELETEs properly, which was previously done via
CHILD_REKEYING, which we don't use anymore since 5c6a62ceb6 as it prevents
reauthentication.
This commit reverts 84738b1a and 2ed5f569.
As we have no DH group available in the KE payload for IKEv1, the verification
can't work in that stage. Instead, we now verify DH groups in the DH backends,
which works for any IKE version or any other purpose.
OpenBSD's isakmpd uses the latest ISAKMP SA to delete other expired SAs.
This caused strongSwan to delete e.g. a rekeyed SA even though isakmpd
meant to delete the old one.
What isakmpd does might not be standard compliant. As RFC 2408 puts
it:
Deletion which is concerned with an ISAKMP SA will contain a
Protocol-Id of ISAKMP and the SPIs are the initiator and responder
cookies from the ISAKMP Header.
This could either be interpreted as "copy the SPIs from the ISAKMP
header of the current message to the DELETE payload" (which is what
strongSwan assumed, and the direction IKEv2 took it, by not sending SPIs
for IKE), or as clarification that ISAKMP "cookies" are actually the
SPIs meant to be put in the payload (but that any ISAKMP SA may be
deleted).
Martin Willi