In particular as responder, this delays costly cryptographic operations
until the IKE_AUTH (or the next IKE_INTERMEDIATE) request is received,
which is preferable to reduce the impact of DoS attacks.
Another advantage is that the key material is not changed until all tasks
built or processed a message so e.g. IntAuth can be calculated with the
current keys without issues.
Both Diffie-Hellman (DH) and Key Encapsulation Mechanism (KEM) based
key exchange methods use a common ke_test_vector format. The
set_seed() function is used to provide deterministic private key
material for the crypto tests.
It also changes that payloads are built before installing the CHILD_SA on
the responder, that is, the KE payload is generated before keys are derived,
so that key_exchange_t::get_public_key() is called before get_shared_secret(),
or it's internal equivalent, which could be relevant for KE implementations
that want to ensure that the key can't be used again after the key
derivation.
This way we can use the IKE_REKEYED state for both redundant and old SAs
to suppress ike_updown().
In the ike-delete task we don't suppress events in state IKE_REKEYING as
that's the case when we delete an SA the peer is currently rekeying with
multiple key exchanges.
This gives us more flexibility with tasks that return NEED_MORE (currently
none of the colliding tasks do, but that will change with multi-KE
rekeyings). The active task has to check itself if the passive task is
done and should be removed from the task manager.
Since f67199378df9 ("ike-rekey: Handle undetected collisions also if
delete is delayed") we only ever track tasks of type TASK_IKE_REKEY, so
there is no need to check the type or use the generic task_t interface.
Also changed some of the comments to clarify collision handling.
If the peer successfully rekeyed the SA it gets marked as IKE_REKEYED
and it remains until the peer deletes it (or a timeout). There is no
point in rekeying such SAs again.
IKE_REKEYING will be relevant if we have multi-KE rekeyings and are
waiting for followup key exchanges for a passive rekeying.
