If the nonce generator detects a stale nonce upon destroy(), it resets
the context in the TKM and releases associated resources in the ID
manager and chunk map.
Also, do not acquire the nonce context ID in tkm_nonceg_create function
but rather when the nonce is actually created by get_nonce().
The nonces created with get_nonce must also be registered in the chunk map.
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
TKM can't verify such signatures so we'd fail in the authorize hook.
Skipping the algorithm identifier doesn't help if the peer uses
anything other than SHA-1, so config changes would be required.
Store the remote instead of the local SPI in the SAD when adding a new
entry in the kernel plugin's add_sa() function.
Since only one ESA context must be destroyed for an inbound/outbound
CHILD SA pair, it does not matter which SPI is used to retrieve it in
the del_sa function.
Update the call to hydra->kernel_interface->expire to make
ees_callback.c compile again. The required destination host argument is
set to NULL for now.
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.
Before this fix it was possible to crash charon with an IKE_SA_INIT
message containing a KE payload with DH group MODP_CUSTOM(1025).
Defining MODP_CUSTOM outside of the two byte IKE DH identifier range
prevents it from getting negotiated.
Fixes CVE-2014-9221.
The TKM Diffie-Hellman plugin now maps IANA DH identifiers to TKM DH
algorithm identifiers. The mapping is specified in the daemon's
'dh_mapping' section in the strongswan.conf file:
dh_mapping {
iana_id1 = tkm_id1
iana_id2 = tkm_id2
iana_id3 = tkm_id3
...
}
Only the mapped IANA IDs are registered as supported DH groups.
Due to problems with the external libraries tkm_init/deinit can't be
called for each test case. Because of this leak detective has to be
disabled for these tests.
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
The TKM credential encoder creates fingerprints of type
KEYID_PUBKEY_INFO_SHA1 and KEYID_PUBKEY_SHA1 using
CRED_PART_RSA_PUB_ASN1_DER.
This makes the pkcs1 plugin unnecessary.
Load complete kernel_netlink plugin instead. Registering the TKM
specific plugins first still ensures that the correct ipsec plugin
is used.
Lazy initialize the RNG_WEAK plugin to avoid the unsatisfiable
soft dependency on startup.
An ALERT_KEEP_ON_CHILD_SA_FAILURE alert is issued when child SA establishment
fails but the corresponding IKE SA is not destroyed. To allow later creation
of child SAs the ISA context must be signaled that the implicity first child SA
creation was skipped.
The IKE and EES sockets are now read from strongswan.conf. They can be
specified like this:
charon-tkm {
ike_socket = /tmp/tkm.rpc.ike
ees_socket = /tmp/tkm.rpc.ees
}
The socket names given above are used by default if none are configured.
The TKM credential set extends the in-memory credential set. It
provides a private key enumerator which is used to instantiate private
key proxy objects on-demand. This allows the usage of private keys with
arbitrary identifiers.
Pass the reqid (of the first child config of an IKE SA) as remote identity id
when calling cc_set_user_certificate. May lead to the usage of the wrong id in
case an IKE SA has multiple child configurations/reqids.
This must be replaced with a proper lookup once the configuration backend is
implemented and provides remote identity ids to charon-tkm.
The key currently imitates the private key of alice@strongswan.org by
returning it's fingerprint in the get_fingerprint function.
This associates the private key with alice's X.509 cert and charon will
use it to create a signature over the local AUTH octets of the test
connection.
The private key serves as a proxy to the TKM ike_isa_sign operation and
extracts the required information from the auth octets chunk passed on
by the keymat.
Store the ISA context id and the initial message in the auth octets
chunk using the sign_info_t struct. Charon will pass on this information
to the TKM private key sign operation where it is extracted.
The key unconditionally returns TRUE for the verify operation if it is called
with a supported signature algorithm. All such verification operations are
performed by the TKM (e.g. trustchain or auth octets verification) anyway, so
this is safe.
The IKE init message sent to us by the peer is needed for authentication
in the authorization hook. Store the message as chunk in the keymat and
provide a getter to make it available.
Extract peer certificate information and build a TKM certificate chain
context in the authorize hook of the tkm_listener_t. The cc context will
be used for ISA authentication using certificates.
The Esa Event Service can be used to trigger ESP SA (ESA) events such as
acquire or expire. The incoming events are forwarded to the hydra kernel
interface for processing.
The responsibility to reset an authenticated endpoint context is passed
from a parent IKE SA keymat to the new keymat by including it in the ISA
info data contained in the skd chunk. The last IKE SA to be destroyed
will also reset the associated AE context.
A child SA is being rekeyed if the esa information passed to the add_sa
function contains nonces. If it also contains a valid Diffie-Hellman
context id PFS is used.
The fact that the encr_r encryption key is passed to add_sa in the
inbound case can be used to determine if we are initiator or not by
inspecting the is_encr_r flag of the esa information struct.
Add additional fields to the esa_info_t struct so the necessary data can
be passed from the keymat to the kernel ipsec interface, where ESA
creation and key generation using the TKM takes place.
The information is used during the inbound add_sa call to create an ESP
SA. This makes the hack of storing the local SPI in a kernel interface
variable between subsequent add_sa calls unnecessary.
An SAD entry is added after successfull creation of a TKM ESA context
in the add_sa() function. The corresponding entry is removed in
del_sa() using the SAD, src, dst, spi and protocol parameters.
Tobias Brunner