As specified by RFC 7296, section 2.6, the data associated with COOKIE
notifications MUST be between 1 and 64 octets in length (inclusive).
Fixes#3160.
This allows using the certificate, which is technically a CA cert, as
end-entity certificate again after the RFC4945-related changes added
with 5.6.3.
Fixes#3139.
If CHILD_SAs are created while waiting for the third QM message we'd not
notice the redundancy and updown events would be triggered unevenly.
This is consistent with the behavior on the initiator, which already does
this check right before installation. Moving the existing check is not
possible due to the narrow hook and moving the installation changes which
peer installs the SAs first and could have other side-effects (e.g. in
error or conflict cases). Still, this might result in CHILD_SA state
discrepancies between the two peers.
Fixes#3060.
If the key type was specified but the ID was NULL or matched a subject, it
was possible that a certificate was returned that didn't actually match
the requested key type.
Closesstrongswan/strongswan#141.
Also expose a method to call arbitrary commands, which allows calling not
yet wrapped commands. Exceptions are raised for all commands if the response
includes a negative "success" key (similar to how it's done in the Python
bindings).
Luckily, the type is only used once when generating payloads and there it
doesn't matter because the encoding rules are the same.
Closesstrongswan/strongswan#135.
Instead of assuming passwords are simply ASCII-encoded we now assume they are
provided UTF-8-encoded, which is quite likely nowadays. The UTF-8 byte
sequences are not validated, however, only valid code points are encoded
as UTF-16LE.
Fixes#3014.
Previously, the initiator would install the SA in transport mode if the
peer sent back the USE_TRANSPORT_MODE notify, even if that was not
requested originally.
The only messages that are generally sent encrypted but could be sent
unencrypted are INFORMATIONALs (currently only used for IKEv1 and ME
connectivity checks). This should prevent issues if the keymat_t behaves
incorrectly and does not return an aead_t when it actually should.
Might be useful for users of other daemons too. Note that compared to the
previous implementation in charon-tkm, the mask/label are applied in
network order.
Closesstrongswan/strongswan#134.
Previously, attributes in an incorrectly sent CFG_REPLY would still be passed
to attribute handlers. This does not prevent handlers from receiving
unrequested attributes if they requested at least one other.
Tobias Brunner