| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
| |
The previous code allowed an attacker to slip in an IKE_SA_INIT with
both SPIs and MID 1 set when an IKE_AUTH would be expected instead.
References #816.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is mandated by the RFCs and it is expected by the task managers.
Initial messages with invalid MID will be treated like regular messages,
so no IKE_SA will be created for them. Instead, if the responder SPI is 0
no SA will be found and the message is rejected with ALERT_INVALID_IKE_SPI.
If an SPI is set and we do find an SA, then we either ignore the message
because the MID is unexpected, or because we don't allow initial messages
on established connections.
There is one exception, though, if an attacker can slip in an IKE_SA_INIT
with both SPIs set before the client's IKE_AUTH is handled by the server,
it does get processed (see next commit).
References #816.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts 8f727d800751 ("Clean up IKE_SA state if IKE_SA_INIT request
does not have message ID 0") because it allowed to close any IKE_SA by
sending an IKE_SA_INIT with an unexpected MID and both SPIs set to those
of that SA.
The next commit will prevent SAs from getting created for IKE_SA_INIT messages
with invalid MID.
Fixes #816.
|
|
|
|
|
|
|
|
|
| |
While the comment is rather clear that we should not adopt live CHILD_SAs
during reauthentication in IKEv2, the code does nonetheless. Add an additional
version check to fix reauthentication if the reauth responder has a replace
uniqueids policy.
Fixes #871.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some conditions it can happen that the CREATE_CHILD_SA exchange for
rekeying the IKE_SA initiated by the peer is successful, but the delete message
does not follow. For example if processing takes just too long locally, the
peer might consider us dead, but we won't notice that.
As this leaves the old IKE_SA in IKE_REKEYING state, we currently avoid actively
initiating any tasks, such as rekeying or scheduled DPD. This leaves the IKE_SA
in a dead and unusable state. To avoid that situation, we schedule a timeout
to wait for the DELETE message to follow the CREATE_CHILD_SA, before we
actively start to delete the IKE_SA.
Alternatively we could start a liveness check on the SA after a timeout to see
if the peer still has that state and we can expect the delete to follow. But
it is unclear if all peers can handle such messages in this very special state,
so we currently don't go for that approach.
While we could calculate the timeout based on the local retransmission timeout,
the peer might use a different scheme, so a fixed timeout works as well.
Fixes #742.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
To quickly check out IKE_SAs and find associated CHILD_SAs, the
child_sa_manager stores relations between CHILD_SAs and IKE_SAs. It provides
CHILD_SA specific IKE_SA checkout functions wrapping the ike_sa_manager.
|
|
|
|
|
|
|
|
|
|
|
| |
As we now use the same reqid for multiple CHILD_SAs with the same selectors,
having marks based on the reqid makes not that much sense anymore. Instead we
use unique marks that use a custom identifier. This identifier is reused during
rekeying, keeping the marks constant for any rule relying on it (for example
installed by updown).
This also simplifies handling of reqid allocation, as we do not have to query
the marks that is not yet assigned for an unknown reqid.
|
|
|
|
|
| |
As the reqid is not that unique even among multiple IKE_SAs anymore, we need
an identifier to uniquely identify a specific CHILD_SA instance.
|
| |
|
|
|
|
| |
Having traffic selectors sorted properly makes comparing them much simpler.
|
|
|
|
|
|
| |
The kernel backend uses an inbound parameter these days, where it makes
no sense to pass the update flag. The kernel backend decides itself how
it handles SA installation based on the inbound flag.
|
|
|
|
|
|
| |
While we can handle the first selector only in BEET mode in kernel-netlink,
passing the full list gives the backend more flexibility how to handle this
information.
|
|
|
|
|
|
|
|
|
|
| |
The reqid is not strictly required, as we set the reqid with the update
call when installing the negotiated SA.
If we don't need a reqid at this stage, we can later allocate the reqid in
the kernel backend once the SA parameters have been fully negotaited. This
allows us to assign the same reqid for the same selectors to avoid conflicts
on backends this is necessary.
|
| |
|
|
|
|
|
|
| |
While they usually are not included in a normal strongSwan build, the XPC
header indirectly defines these Mach types. To build charon-xpc, which uses
both XPC and strongSwan includes, we have to redefine these types.
|
| |
|
| |
|
|
|
|
| |
pki tool
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
|
|
|
| |
We currently send the notify in Main Mode only, as it is explicitly not allowed
by RFC 2407 to send (unprotected) notifications in Aggressive Mode. To make
that work, we'd need to handle that notify in Aggressive Mode, which could
allow a MitM to inject such notifies and do some harm.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
|
|
| |
We assume that a responder is behind a static NAT (e.g. port forwarding)
and allow remote address updates in such situations.
The problem described in RFC 5996 is only an issue if the NAT mapping
can expire.
|
|
|
|
|
|
|
|
| |
I still think ipsec/l2tp with fragmentation support is a useful
fallback option in case the Windows IKEv2 connection fails because
of fragmentation problems.
Tested with Windows XP, 7 and 8.1.
|
|
|
|
|
|
|
| |
For instance, if a DPD exchange is initiated by the gateway when a
mobile client is roaming and it then gets a new IP address and sends
an address update via MOBIKE, the DPD retransmits would still be sent
to the old address and the SA would eventually get closed.
|
|
|
|
|
| |
If a fragmented message is retransmitted only the first packet is passed
to the alert() hook.
|
| |
|
|
|
|
|
| |
This fails if there are unencrypted payloads before an encrypted
fragment payload in the first fragment.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The message() hook on bus_t is now called exactly once before (plain) and
once after fragmenting (!plain), not twice for the complete message and again
for each individual fragment, as was the case in earlier iterations.
For inbound messages the hook is called once for each fragment (!plain)
and twice for the reassembled message.
|
| |
|
| |
|