ikev2: Delay online revocation checks during make-before-break reauthentication

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.
This commit is contained in:
Tobias Brunner
2016-03-10 11:07:15 +01:00
parent 8ce78e43a4
commit f1cbacc5d1
+5
View File
@@ -35,6 +35,7 @@
#include <sa/ikev2/tasks/ike_config.h>
#include <sa/ikev2/tasks/ike_dpd.h>
#include <sa/ikev2/tasks/ike_vendor.h>
#include <sa/ikev2/tasks/ike_verify_peer_cert.h>
#include <sa/ikev2/tasks/child_create.h>
#include <sa/ikev2/tasks/child_rekey.h>
#include <sa/ikev2/tasks/child_delete.h>
@@ -1655,8 +1656,12 @@ static void trigger_mbb_reauth(private_task_manager_t *this)
}
enumerator->destroy(enumerator);
/* suspend online revocation checking until the SA is established */
new->set_condition(new, COND_ONLINE_VALIDATION_SUSPENDED, TRUE);
if (new->initiate(new, NULL, 0, NULL, NULL) != DESTROY_ME)
{
new->queue_task(new, (task_t*)ike_verify_peer_cert_create(new));
new->queue_task(new, (task_t*)ike_reauth_complete_create(new,
this->ike_sa->get_id(this->ike_sa)));
charon->ike_sa_manager->checkin(charon->ike_sa_manager, new);