| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
As per RFC 7296, 2.25.2 (what we did before was the behavior described
in RFC 4718).
|
| |
|
|
|
|
| |
rekeyed/deleted/established
|
| |
|
| |
|
|
|
|
|
| |
RFC 7296 explicitly says we SHOULD reply as usual and forget about our
own close request.
|
|
|
|
|
|
|
|
|
| |
This makes handling such IKE_SAs more specifically compared to keeping them
in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a
collision - even triggering the ike_updown event), or using IKE_REKEYING for
them, which would also be ambiguous.
For instance, we can now reject anything but DELETES for such SAs.
|
| |
|
|
|
|
|
|
| |
Moving to the new SA only after receiving the DELETE for the old SA was
not ideal as it rendered the new SA unusable (because it simply didn't
exist in the manager) if the DELETE was delayed/got dropped.
|
|
|
|
|
|
| |
This happens if the peer deletes the redundant SA before we are able to
handle the response. The deleted SA will be in state CHILD_INSTALLED but
we don't want to trigger the child_updown() event for it or recreate it.
|
| |
|
|
|
|
|
| |
This happens if there is a rekey collision and the peers disagree on the
DH group.
|
|
|
|
| |
This allows handling collisions better, in particular with deletions.
|
|
|
|
|
|
| |
getting deleted
These are the notifies we should return according to RFC 7296.
|
| |
|
|
|
|
|
| |
We will later add code to retry creating the CHILD_SA if we are not
rekeying. Rekeying is already rescheduled as with any other errors.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generally, we will not find the CHILD_SA by searching for it with the
outbound SPI (the initiator of the DELETE sent its inbound SPI) - and if
we found a CHILD_SA it would most likely be the wrong one (one in which
we used the same inbound SPI as the peer used for the one it deletes).
And we don't actually want to destroy the CHILD_SA at this point as we
know we already initiated a DELETE ourselves, which means that task
still has a reference to it and will destroy the CHILD_SA when it
receives the response from the other peer.
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
| |
Fixes #1380.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 also update the auth config so the constraints are not enforced.
|
|
|
|
| |
enumerator
|
|
|
|
| |
As we use a different rule we can always store the scheme.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Also don't query redirect providers in this case.
|
| |
|
| |
|
|
|
|
|
|
| |
To prevent the creation of the CHILD_SA we set a condition on the
IKE_SA. We also schedule a delete job in case the client does not
terminate the IKE_SA (which is a SHOULD in RFC 5685).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This moves hydra->kernel_interface to charon->kernel.
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
|
|
|
| |
When handling a rekey collision we might have to delete an already
installed redundant CHILD_SA (or expect the other peer to do so).
We don't want to trigger updown events for these as neither do we do
so for successfully rekeyed CHILD_SAs.
Fixes #853.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some scenarios an IKE_SA might get restarted multiple times (e.g.
due to retransmits and delayed INVALID_KE_PAYLOAD notifies) so that
two IKE_SA_INIT messages might be sent that only differ in the
previously randomly generated NAT_DETECTION_SOURCE_IP payload.
This could cause an authentication failure on the responder if the two
peers don't use the same IKE_SA_INIT message in their InitiatorSignedOctets.
While the payload is generated in a reproducible way it will still change
when the daemon is restarted, which should make detecting the payloads
as fake a bit harder (compared to e.g. just using 0.0.0.0:0 as address).
Fixes #1131.
|