Tobias Brunner [Fri, 25 Oct 2024 10:48:52 +0000 (12:48 +0200)]
traffic-selector: Add workaround for possibly bogus warning with GCC 14
When compiling with -O3 with GCC 14, we get the following warning/error:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: error: '__builtin_memcpy' offset [0, 3] is out of the bounds [0, 0] [-Werror=array-bounds=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
Which seems completely bogus as that array has a fixed size of 16 and
some weird workarounds remove the warning (e.g. adding an assignment
to `subset->netbits` before the `memcpy()`). This is also the only
place GCC complains about and we use `memcpy()` all over the place
in this file to set those addresses.
Tobias Brunner [Mon, 28 Oct 2024 14:12:32 +0000 (15:12 +0100)]
ml: Store decoded public/private key and matrix A on initiator
While this does require quite a bit of memory, on initiators there are
usually fewer concurrent SAs getting created so this should be less of
an issue than on a gateway that handles lots of SAs as responder.
The speed up is about 30% on the initiator during the decapsulation,
while the key generation does take a bit more time (about 3%).
Tobias Brunner [Mon, 21 Oct 2024 08:38:14 +0000 (10:38 +0200)]
ml: Add software implementation of ML-KEM
This follows FIPS 203 relatively closely but takes some ideas from the
reference implementation. In particular, how to avoid potential
side-channels via direct C division/modulo operations. However, it just
uses Barrett reduction (no Montgomery reduction) and no negative
coefficients to avoid number format conversions and keep the
implementation clearer.
Gerardo Ravago [Fri, 4 Oct 2024 14:26:16 +0000 (10:26 -0400)]
openssl: Add ML-KEM support with AWS-LC
This registers support for the ML_KEM_{512,768,1024} key exchange
algorithms in the `openssl` plugin when built using AWS-LC as the
libcrypto. To do this, we introduce the `openssl_kem` source files
which implement the key exchange algorithm using the Key Encapsulation
Mechanism (KEM) API. Future KEM algorithms can be implemented
generically using this interface by substituting the appropriate NIDs.
It also supports both seeded (via DRBG) and unseeded modes depending
on the user's requirements for KATs or entropy sources.
It should be noted that this does not add support for KEM algorithms
within upstream OpenSSL and is API incompatible. Future work will need
to condition out the incompatibilities as-appropriate. However, the
high-level logic should be the same for all KEMs and KEM APIs.
Andreas Steffen [Mon, 4 Nov 2019 21:22:47 +0000 (22:22 +0100)]
key-exchange: Joint ke_test_vector format for DH and KEM
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.
mem-pool: Fix issue with make-before-break reauth and multiple IKE_SAs
If uniqueness checks are disabled and multiple IKE_SAs with the same
identities are created, an offline lease could have gotten reassigned
during a make-before-break reauthentication if such an SA was closed
earlier. Checking for an online lease for the same client (IP/port)
first ensures that the correct IP is reassigned during the
reauthentication.
Tobias Brunner [Fri, 18 Oct 2024 07:14:27 +0000 (09:14 +0200)]
socket-default: Always open IPv4 sockets before IPv6 sockets
Since we now open sockets for each address family independently (via
IPV6_V6ONLY) and without SO_REUSEADDR, it could happen with the previous
order on Linux that opening the port that was allocated as ephemeral
port for IPv6 was already used by a different process for IPv4.
Most IPv6 sockets on ephemeral ports will not have IPV6_V6ONLY set, so
the same port is also reserved for IPv4. Therefore, it's save to assume
that any ephemeral port we first get for IPv4 is free for IPv6.
Tobias Brunner [Fri, 27 Aug 2021 16:18:09 +0000 (18:18 +0200)]
tun-device: Fix handling of IPv6 addresses
struct ifreq can't be used for IPv6 as the ifr_addr member is not large
enough. Actually, configuring an IPv6 address via an AF_INET socket won't
work anyway. And unfortunately, it's not standardized how IPv6 addresses
are installed, so we have to do this quite differently on Linux and on BSD.
However, we already use SIOCAIFADDR for IPv4 on newer FreeBSD systems,
which wasn't the case when this patch was originally created in 2014.
Consider queued child-creating tasks when reloading configs that have
`start` as start action. Besides some possible corner cases it fixes
handling IKE_SAs that are current getting established and have no
established CHILD_SAs yet.
Thomas Egerer [Fri, 6 Sep 2024 11:29:40 +0000 (13:29 +0200)]
array: Don't use realloc() with zero size in array_compress()
The behavior of realloc(3) with zero size was apparently implementation
defined. While glibc documents the behavior as equivalent to free(3),
that might not apply to other C libraries. With C17, this behavior has
been deprecated, and with C23, the behavior is now undefined. It's also
why valgrind warns about this use.
Hence, when array_compress() would call realloc() with a zero size, we
now call free() explicitly and set the pointer to NULL.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Tobias Brunner [Wed, 7 Aug 2024 14:20:42 +0000 (16:20 +0200)]
Merge branch 'multi-ke'
This adds support for multiple key exchanges (no KEMs yet as none are
standardized so far). Work on this started over five years ago and went
through multiple iterations (first our own protocol, then standardized
extensions in different variations).
IKE_INTERMEDIATE exchanges, defined RFC 9242, are used to transport
multiple KE payloads between the IKE_SA_INIT and IKE_AUTH exchanges.
To rekey IKE and CHILD_SAs with multiple key exchanges, IKE_FOLLOWUP_KE
exchanges are used, as defined in RFC 9370.
In proposals, additional key exchange methods are configured via `keX_`
prefix, where X is a number between 1 and 7. For example, `ke1_ecp256`
adds ECP_256 as additional KE method. As with regular key exchanges,
peers have to agree on a method for each round unless no algorithms are
defined by both or `keX_none` is configured to make that round explicitly
optional.
Also changed is how rekey collisions are handled, which makes CHILD_SAs
properly trackable via child_rekey() hook.
unit-tests: Ensure listeners can track SAs via ike/child_updown/rekey()
Previously, it could happen that child_rekey() was triggered twice for
the same "old" SA. For listeners that would mean they'd loose track as
they'd be tracking a new SA that wasn't relevant anymore and for which
no updown event would ever get triggered (it was the redundant SA in a
collision). This new assert ensures that events are triggered in a
predictable way and listeners can track SAs properly.
Tobias Brunner [Mon, 22 Aug 2022 13:43:16 +0000 (15:43 +0200)]
ikev2: Make CHILD_SAs properly trackable during rekey collisions
As the winner of a rekey collision, we previously always triggered the
child_rekey() event once when creating the redundant SA on behalf of the
peer in the passive child-rekey task and then a second time when
creating the winning SA in the active task. However, both calls passed
the replaced CHILD_SA as "old". This made tracking CHILD_SAs impossible
because there was no transition from the redundant, "new" SA of the
first event to the "new", winning SA of the second. Of course, when the
second event was triggered, the redundant SA might not have existed
anymore because the peer is expected to delete it, which could happen
before the CREATE_CHILD_SA response arrives at the initiator.
This refactoring ensures that the child_rekey() event is triggered in
a way that makes the CHILD_SAs trackable in all reasonable (and even
some unreasonable) scenarios. The event is generally only triggered
once after installing the outbound SA for the new/winning CHILD_SA.
This can be when processing the CREATE_CHILD_SA in the active child-rekey
task, or when processing the DELETE for the old SA in a passive
child-delete task. There are some cases where the event is still
triggered twice, but it is now ensured that listeners can properly
transition to the winning SA.
Some corner cases are now also handled correctly, e.g. if a responder's
DELETE for the new CHILD_SA arrives before its CREATE_CHILD_SA response
that actually creates it on the initiator. Also handled properly are
responders of rekeyings that incorrectly send a DELETE for the old
CHILD_SA (previously this caused both, the new and the old SA, to get
deleted).