This replaces the EAP-Identity with the EAP-MSCHAPv2 username, which
ensures the client is known with an authenticated identity. Previously
a client with a valid username could use a different identity (e.g. the
name of a different user) in the EAP-Identity exchange. Since we use
the EAP-Identity for uniqueness checks etc. this could be problematic.
The EAP-MSCHAPv2 username is now explicitly logged if it is different
from the EAP-Identity (or IKE identity).
Fixes#1182.
This is particularly important for single valued rules (e.g.
identities). When copying values this is already handled correctly
by the enumerator and add().
In Java all integer types are signed, when a negative integer is casted
to a larger type (e.g. int to long) then due to sign extension the upper
bytes are not 0. So writing that value to a byte array does not produce
the expected result. By overloading the putX() methods we make sure to
upcast the values correctly.
Since we don't use the kernel-netlink plugin anymore and the headers
in the NDK are reasonably recent, we don't need this anymore (at least
when building the app).
Fixes#1172.
We already did so during Phase 1 but because all three Quick Mode
message have the same message ID we occasionally dropped the third
message as retransmit, so we do it there too. For INFORMATIONAL
and TRANSACTION exchanges we don't expect more than one inbound message
with the same message ID so we still use them there.
Fixes#1198.
If the (un)registering of a kernel interface (net or ipsec) fails, the
plugin loader will never know, since the appropriate functions always
returns TRUE. By making the (un)register functions return a boolean
value, the loader can detect a failure during initializing the kernel
interface and abort charon startup if desired.
This ensures we don't pass data (via msg_control) defined in a different
scope to sendmsg(). Actually, some compilers (e.g. GCC 5.2.1) might
optimize the memcpy() call away causing the packets not to get sent from
the intended source address.
It also makes the code clearer than with all these ifdefs.
Fixes#1171.
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.
If the job gets queued for a newly created IKE_SA it might not yet be
checked in when the job is running, reschedule the job in that case.
This should fix the two p2pnat test scenarios, which occasionally
failed because one of the peers did not initiate the connection to
the mediation server.
