Previously the constraints in the authentication configuration of an
initiator were enforced only after all authentication rounds were
complete. This posed a problem if an initiator used EAP or PSK
authentication while the responder was authenticated with a certificate
and if a rogue server was able to authenticate itself with a valid
certificate issued by any CA the initiator trusted.
Because any constraints for the responder's identity (rightid) or other
aspects of the authentication (e.g. rightca) the initiator had were not
enforced until the initiator itself finished its authentication such a rogue
responder was able to acquire usernames and password hashes from the client.
And if a client supported EAP-GTC it was even possible to trick it into
sending plaintext passwords.
This patch enforces the configured constraints right after the responder's
authentication successfully finished for each round and before the initiator
starts with its own authentication.
Fixes CVE-2015-4171.
Global reqid allocation (94eb09ac) broke fixed reqid allocation. Resupport them
by bypassing allocation in the kernel if a fixed reqid has been configured.
Fixes#976.
This fixes a DoS and potential remote code execution vulnerability that was
caused because the original payload type that was returned previously was
used to cast such payload objects to payloads of the indicated type (e.g.
when logging notify payloads with a payload type for the wrong IKE version).
Fixes CVE-2015-3991.
When using a cipher with sequential IVs, we never must pass an identical IV
to the IV generator. To avoid it when using IKEv2 fragmentation, use the lower
bits of the 64-bit message ID as the fragment number.
Only one of `--user-install` and `--install-dir` may be set and if
`--user-install` is the default on a system installation will fail
unless we disable it explicitly.
Fixes#914.
Installing them might not work well when building distro packages (e.g.
with DESTDIR installs). It might be easier to install them later with a
script in the distro package.
When building from source on the local system it could still be useful to
install the packages directly, which can be enabled with separate configure
options.
The main problem with DESTDIR installations of the Python Egg is that
easy_install creates or modifies a file called easy-install.pth in the
installation directory. So it's not actually possible to simply copy
the results in DESTDIR over to the actual system as that file would have
to be merged with any existing one.
Fixes#914.
We also don't require setup.py to exist during cleanup, as e.g. with
make distcheck the source directory is not writable when the build directory
is cleaned, so setup.py can't be created (to just get removed again anyway
if VICI and the Python Eggs haven't been enabled previously).
Instead of just implicitly destroying the old SA we properly delete it to
notify the other peer (if the other peer keeps the SA up after the
reauthentication and sends DPDs it might consider us dead even though the
new SA is up, that seems to be the case with racoon). We delay the DELETE
a bit to give the other peer time to get the new SA fully established.
Since DELETE messages are not retransmitted it is still possible that
the other peer misses that we deleted the SA.
The interface is currently not very nice, but if we ever were able to
safely checkout multiple SAs concurrently we could add something similar
to ike_rekey() and call that when we detect a reauthentication.
There are several situations that the previous code didn't handle that
well, for example, interim updates during rekeying (until the rekeyed SA
was deleted the numbers were too high, then suddenly dropped afterwards),
or rekeying for IKEv1 in general because rekeyed IPsec SAs stay installed
until they expire (so if they were still around when the IKE_SA was
terminated, the reported numbers in the Stop message were too high).
If intermediate updates are not used the cache entries for rekeyed
CHILD_SA will accumulate, we can't clean them up as we don't get
child_updown() events for them.
Returning FAILED in the constructor is wrong, but returning NULL doesn't work
either as it's currently assumed tasks always can be created.
Therefore, delay this check until we actually try to allocate a nonce.
This allows to control the life-cycle of a nonce in the context of the
ike init task. In the TKM use-case the nonce generator cannot be
destroyed before the ike init task is finalized, otherwise the created
nonce is detected as stale.
This allows to control the life-cycle of a nonce in the context of the
child create task. In the TKM use-case, it is required to reset the
nonce context if the created nonce is not consumed. This happens if the
child SA negotiation fails and it is detected before the SA is
established via the TKM kernel plugin (i.e. rekey collision).
If id is not specified and certificate authentication is used, use the
certificate subject name as identity. Simplifies configuration as in most cases
this is the right thing to do.
Signed-off-by: Timo Teräs <[email protected]>
libvici currently relies on libstrongswan, and therefore is bound to the GPLv2.
But to allow alternatively licensed reimplementations without copyleft based
on the same interface, we liberate the header.
If a vici client registered for (control-)log events, but a vici read/write
operation fails, this may result in a deadlock. The attempt to write to the
bus results in a vici log message, which in turn tries to acquire the lock
for the entry currently held.
While a recursive lock could help as well for a single thread, there is still
a risk of inter-thread races if there is more than one thread listening for
events and/or having read/write errors.
We instead log to a local buffer, and write to the bus not before the connection
entry has been released. Additionally, we mark the connection entry as unusable
to avoid writing to the failed socket again, potentially triggering an error
loop.
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
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).
The specific traffic selectors from the acquire events, which are derived
from the triggering packet, are usually prepended to those from the
config. Some implementations might not be able to handle these properly.
References #860.
The verification introduced with 84738b1aed ("encoding: Verify the length
of KE payload data for known groups") can't be done for IKEv1 as the KE
payload does not contain the DH group.
Martin Willi