From: Tobias Brunner Date: Wed, 29 Jun 2022 08:29:16 +0000 (+0200) Subject: Merge branch 'multi-ke-backport' X-Git-Tag: 5.9.7dr2~1 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=30faf04e92dc483f2da3f3f1834243fe7d333ae5;p=thirdparty%2Fstrongswan.git Merge branch 'multi-ke-backport' 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. --- 30faf04e92dc483f2da3f3f1834243fe7d333ae5