We do these checks after the SA is fully established.
When establishing an SA the responder is always able to install the
CHILD_SA created with the IKE_SA before the initiator can do so.
During make-before-break reauthentication this could cause traffic sent
by the responder to get dropped if the installation of the SA on the
initiator is delayed e.g. by OCSP/CRL checks.
In particular, if the OCSP/CRL URIs are reachable via IPsec tunnel (e.g.
with rightsubnet=0.0.0.0/0) the initiator is unable to reach them during
make-before-break reauthentication as it wouldn't be able to decrypt the
response that the responder sends using the new CHILD_SA.
By delaying the revocation checks until the make-before-break
reauthentication is completed we avoid the problems described above.
Since this only affects reauthentication, not the original IKE_SA, and the
delay until the checks are performed is usually not that long this
doesn't impose much of a reduction in the overall security.
On failure the SA is deleted and reestablished as configured. The task
is activated after the REAUTH_COMPLETE task so a make-before-break reauth
is completed before the new SA might get torn down.
We already do this in the trusted public key enumerator (which
internally uses the trusted certificate enumerator) but should do so
also when this enumerator is used directly (since the public key
enumerator has the read lock the additional call will just be skipped
there).
Our default config files are very charon specific. So to avoid
confusion when only charon-systemd is installed we just default to all
settings defined for charon. Since charon-systemd probably won't be used
together with charon this should not cause conflicts (settings may still
be overridden via the charon-systemd section).
Because settings are already accessed in library_init(), calling
add_fallback() externally after calling library_init() is not ideal.
This way namespaces already serve as fallback while library_init() is
executed and they are also in the correct order so that libstrongswan is
always the last root section.
This also restores the charon.signature_authentication_constraints
functionality, that is, if no explicit IKE signature schemes are
configured we apply all regular signature constraints as IKE constraints.
This allows for different signature schemes for IKE authentication and
trustchain verification.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
An attacker could blindly send a message with invalid nonce data (or none
at all) to DoS an initiator if we just destroy the SA. To prevent this we
ignore the message and wait for the one by the correct responder.
If the SA got redirected this would otherwise cause a reauthentication with
the original gateway. Reestablishing the SA to the original gateway, if e.g.
the new gateway is not reachable makes sense though.
We handle this similar to how we do reestablishing IKE_SAs with all CHILD_SAs,
which also includes the one actively queued during IKE_AUTH.
To delete the old SA we use the recently added ike_reauth_complete task.
Tobias Brunner