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.
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: 32df0d81fb ("child-create: Destroy nonceg in migrate()")
Since 11c14bd2f5 CA certificates referenced in ca sections were
enumerated by two credential sets if they were also stored in
ipsec.d/cacerts. This caused duplicate certificate requests to
get sent. All CA certificates, whether loaded automatically or
via a ca section, are now stored in stroke_ca_t.
Certificates referenced in ca sections are now also reloaded
when `ipsec rereadcacerts` is used.
In some cases the third message of a Quick Mode exchange might arrive
after the first message of a subsequent Quick Mode exchange. Previously
these messages were handled incorrectly and the second Quick Mode
exchange failed.
Some implementations might even try to establish multiple Quick Modes
simultaneously, which is explicitly allowed in RFC 2409. We don't fully
support that, though, in particular in case of retransmits.
Fixes#1076.
While this doesn't really create any problems it is not 100% correct to
accept such messages because, of course, the sender of an IKE_SA_INIT
request is always the original initiator of an IKE_SA.
We currently don't check the flag later, so we wouldn't notice if the
peer doesn't set it in later messages (ike_sa_id_t.equals doesn't
compare it anymore since we added support for IKEv1, in particular since
17ec1c74de).
If multiple certificates use the same subjects we might choose the wrong
one otherwise. This way we use the one referenced with leftcert and
stored in the auth-cfg and we actually do the same thing later in the
pubkey authenticator.
Fixes#1077.
This allows symmetric configuration of EAP methods (i.e. the same value
in leftauth and rightauth) when mutual EAP-only authentication is used.
Previously the client had to configure rightauth=eap or rightauth=any,
which prevented it from using this same config as responder.
When reestablishing the IKE_SA we should still use the original port
when right resolves to %any as some implementations might not like
initial IKE messages on port 4500 (especially for IKEv1).
This may happen if something like `echo ... > /path/to/fifo` is used
before the plugin was able to create the FIFO. In that case we'd end
up in a loop always reading the same values from the static file.
Some implementations don't send a Key Length attribute for AES-128.
This was allowed for IKE in early drafts of RFC 3602, however, some
implementations also seem to do it for ESP, where it never was allowed.
And the final version of RFC 3602 demands a Key Length attribute for both
phases so they shouldn't do it anymore anyway.
Fixes#1064.
During a rekeying we want to reuse the current reqid, but if the new SA
does not allocate it via kernel-interface the state there will disappear
when the old SA is destroyed after the rekeying. When the IKE_SA is
later reauthenticated with make-before-break reauthentication the new
CHILD_SAs there will get new reqids as no existing state is found in the
kernel-interface, breaking policy installation in the kernel.
Fixes: a49393954f ("child-sa: Use any fixed reqid configured on the CHILD_SA config")
Vendor specific EAP methods may be registered with:
PLUGIN_CALLBACK(eap_method_register, <constructor>),
PLUGIN_PROVIDE(EAP_SERVER_VENDOR, <type>, <vendor>),
Same for client implementations via EAP_PEER_VENDOR.
References #969.
strongSwan uses PrintableString when encoding DNs from strings (if the
character set permits it, otherwise T61String is currently used) but
certificates might be encoded with UTF8String even for simple ASCII strings.
By ignoring this string type when hashing RDNs we make sure the same hash
results in this case as long as the actual string values are the same.
Fixes#991.
If a client does Mode Config during reauthentication the assign_vips()
event might be triggered twice, we should not send another Start message
in that case.
Fixes#937.
Some clients won't do Mode Config or XAuth during reauthentication.
Because Start messages previously were triggered by TRANSACTION exchanges
none were sent for new SAs of such clients, while Stop messages were still
sent for the old SAs when they were destroyed. This resulted in an
incorrect state on the RADIUS server.
Since 31be582399 the assign_vips() event is also triggered during
reauthentication if the client does not do a Mode Config exchange.
So instead of waiting for a TRANSACTION exchange we trigger the Start
message when a virtual IP is assigned to a client.
With this the charon.plugins.eap-radius.accounting_requires_vip option
would not have any effect for IKEv1 anymore. However, it previously also
only worked if the client did an XAuth exchange, which is probably
rarely used without virtual IPs, so this might not be much of a
regression.
Fixes#937.
If AEAD algorithms are used no integrity algorithm will be received from
the other HA node. But since AUTH_UNDEFINED is 1024 and not 0 this value
was incorrectly added to the proposal, resulting in a failure during key
derivation. The variables are now explicitly initialized to 0, as already
was the case for the IKE SAs.
Fixes#1051.
When the IKE_SA is synced without the remote address, after a
reauthentication charon is not able to find it in its connected_peers
table since the destination host will be %any (it's missing in the
message, hence the default from the newly created ike_sa_t -- %any --
will be used).
By adding the value to the HA_IKE_ADD message, we should be able to
solve this problem.
Signed-off-by: Thomas Egerer <[email protected]>
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.
When flush() is called there might be threads in install() waiting for
trap policies to get installed (without holding the lock). We have to
wait until they updated the entries with the respective CHILD_SAs before
destroying the list.
We also have to prevent further trap policy installations (and wait until
threads in install() are really finished), otherwise we might end up
destroying CHILD_SA objects after the kernel interface implementations
have already been unloaded (avoiding this is the whole point of calling
flush() before unloading the plugins).
This fixes potential race conditions in case complete() or flush() is
executed before or concurrently with a thread that handles an acquire.
It will also simplify tracking multiple acquires created for the same
trap policy in the future.
Also fixes the behavior in some error situations.
Tobias Brunner