]> git.ipfire.org Git - thirdparty/strongswan.git/commitdiff
Merge branch 'multi-ke-backport'
authorTobias Brunner <tobias@strongswan.org>
Wed, 29 Jun 2022 08:29:16 +0000 (10:29 +0200)
committerTobias Brunner <tobias@strongswan.org>
Wed, 29 Jun 2022 09:18:28 +0000 (11:18 +0200)
This merge includes changes that were created for the upcoming IKEv2
extension for multiple key exchanges over the last four years, but which
are not directly related to the actual protocol changes.

Changes include renaming diffie_hellman_t to the more generic
key_exchange_t (also renamed are some of the interface's methods),
making utility functions that deal with DH groups more generic, and let
tasks handle the first IKE_AUTH message more reliably by not depending
on e.g. specific message IDs.

One significant change is delaying the IKEv2 key derivation until
the keys are actually needed to process or send the next message.  So
instead of deriving the keys directly while processing an IKE_SA_INIT
request (which could come from a spoofed address), this is delayed until
the corresponding IKE_AUTH request is received.  Implementations of the
key_exchange_t interface are now expected to do the key derivation and
any costly public key validation in get_shared_secret() and not
set_public_key().

Sent IKE_SA_INIT messages are now also not pre-generated anymore to collect
their encoding for the authentication.  Instead, a new post_build() hook
allows the ike-auth task to do so after the actual message has been built,
which allows later tasks and plugins (via message() hook) to modify the
message (e.g. add notifies) after the ike-auth task's build() method
already ran.

Also changed is how inbound requests are processed and retransmits are
detected.  Instead of parsing all inbound messages right away (which
might trigger a key derivation or require keys we don't have anymore in
the multi-KE use case), we now first check a request's message ID and
compare its hash to that of the previous request to decide if it's a
valid retransmit.  For fragmented messages, we only keep track of the
first fragment so we can send the corresponding response immediately if
a retransmit of it is received, instead of waiting for all fragments
and reconstructing the message, which we did before.


Trivial merge