| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fixes #1380.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
These might have changed by a peer-initiated MOBIKE address update.
Fixes #1125.
|
|
|
|
| |
deleting the SA
|
|
|
|
|
| |
This allows us to DELETE CHILD_SAs on failures that occur before we
retrieved the selected proposal.
|
|
|
|
|
|
|
| |
information
Since we only support single protocols we could probably guess it and always
send a DELETE.
|
|
|
|
|
|
|
| |
When retrying due to a DH group mismatch this is already done by the
child-create task itself. And in other cases where the task returns
NEED_MORE we actually will need access to a possible proposal to properly
delete it.
|
|
|
|
|
|
|
|
|
|
| |
mismatch
If the responder declines our KE payload during a CHILD_SA rekeying migrate()
is called to reuse the child-create task. But the child-rekey task then
calls the same method again.
Fixes: 32df0d81fb46 ("child-create: Destroy nonceg in migrate()")
|
| |
|
|
|
|
|
| |
Even when there is no error the CREATE_CHILD_SA response should be sent
in the context of the existing IKE_SA.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The destroy() method sets the IKE_SA on the bus to NULL, we reset it to
the current IKE_SA so any events and log messages that follow happen in
the correct context.
A practical example where this is problematic is a DH group mismatch,
which causes the first CREATE_CHILD_SA exchange to fail. Because the SA
was not reset previously, the message() hook for the CREATE_CHILD_SA
response, for instance, was triggered outside the context of an IKE_SA,
that is, the ike_sa parameter was NULL, which is definitely not expected
by several plugins.
Fixes #862.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
authentication
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.
|
|
|
|
|
| |
Since another nonce gets allocated later (if any was allocated already)
this would have resulted in a leaked nonce context ID when used in charon-tkm.
|
|
|
|
| |
As with ike-init we can't return NULL in the task constructor.
|
|
|
|
|
|
| |
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).
|
|
|
|
|
| |
The parameter indicates if the alert is raised upon failure to establish
the first CHILD SA of an IKE SA.
|