On Sat, Jan 11, 2025 at 09:52:17AM GMT, Paul Wouters wrote: > On Jan 11, 2025, at 08:09, Loganaden Velvindron <logana...@gmail.com> wrote: > > > > This might have slipped due to holidays last year. > > > > I would like to know if there is any interest in documenting the use of > > x25519-sntrup761 as used in OpenIKED ? > > I know strongswan had a lot of experimental PQ algos, including NewHope and > NTRUprime. These predate the INTERMEDIATE and ADDITIONAL_KE methods later > designed to carry PQ algorithms. > > I am not aware of what openiked has implemented. This old strongswan testing > stuff or some private use code point using the new stuff. The old strongswan > mechanisms are not what is being standardized with IKE now. Do you know more > about what implementation openiked used ? > > But also, personally I am not interested in NTRUprime at this point. I am > interested in a pure mlkem and 25519mlkem hybrid. Possibly frodokem as > alternative for mlkem. > > Paul
Hi Paul, the OpenIKED implementation is comparable to the strongswan experiments. It also predates INTERMEDIATE and ADDITIONAL_KE and is based on the same x25519 + NTRUprime construction that OpenSSH has been shipping for a while now. It adds a new private datapoint and treats the hybrid construction as a single KE. Since ML-KEM has since been chosen as winner and OpenSSH has added a ML-KEM768 + X25519 variant recently [1] I'd also be interested in adding something like that at some point. Tobias [1] https://github.com/openssh/openssh-portable/commit/f68312eb593943127b39ba79a4d7fa438c34c153 > > > > > > >> On Thu, 19 Dec 2024 at 12:08, Loganaden Velvindron <logana...@gmail.com> > >> wrote: > >> > >> Hi All, > >> > >> The OpenBSD project develops its own IPsec implementation known as > >> OpenIKED. > >> > >> OpenIKED supports x25519+sntrup761 as a key exchange with the following > >> option: > >> 'ikesa group sntrup761x25519' > >> > >> OpenBSD users are already using this in production: > >> See this email: > >> " > >> Hi David, Hi tech@, > >> > >> I somehow managed to configure a few sec(4) interfaces and everything > >> worked > >> fine yesterday. This morning as i got up I noticed my nightly recycling of > >> pppoe0 broke everything. I tried to bring it back but noticed that no > >> flows > >> would be installed by iked. I had to revert yesterdays configuration of > >> changing everything to sec(4). > >> > >> I have a dynamic IP through an ISP in germany which outsourced the last > >> mile > >> to telekom (DTAG). What I do is I go through everything through my cloud > >> provider by IPSEC'ing the traffic from the dynamic IP to the cloud VPS. It > >> works well except in one aspect. The IPSEC without sec(4) is doggedly > >> slow, > >> so there has to be something like an MTU issue or something. To make > >> matters > >> a little more complicated, I have a wireguard tunnel inside the IPSEC so > >> it's > >> doubly encrypted with AES 256. This has a caveat that when the IPSEC is > >> not > >> configured with iked, the wireguard will not initiate either as the telekom > >> or this ISP have installed certain filters preventing wireguards initiation > >> signature. However once it is initiated it will function nicely. > >> > >> My pppoe0 when it connects has only 1 route, to the VPS. It does not have > >> a default route. For sec0 it was weird configuring it with an IP of > >> 0.0.0.0/0 > >> or 0.0.0.2/0 to indicate that it is of dynamic nature and I don't know > >> before- > >> hand what the IP is going to be. I somehow believe that this caused > >> problems > >> and sec(4) is not really meant to be on dynamic PPPoE. > >> > >> I propose this pseudo-driver change: Much like vlan(4) it should be > >> configured > >> on top of the physical or other pseudo interface, that way it knows it's > >> dynamic IP. The condition it will dynamically do this is when the source > >> IP > >> is in the 0.0.0.0/24 netblock. For the other side it's reversed we know > >> the > >> source IP but not the destination, configuring it to the 0.0.0.0/24 > >> netblock > >> again should be indication enough that this is an arbitrary IP somewhere on > >> the Internet. The same concept could be done or IPv6 configs. > >> > >> I'd be willing to look into this but my TODO is growing and growing, I > >> can't. > >> I have too many projects on my plate right now. I'll let you in on my > >> dynamic > >> IPSEC/IKED config. > >> > >> ... > >> ikev2 passive transport esp from $self_ip to $telekom_ip1 \ > >> ikesa enc aes-256-gcm \ > >> group sntrup761x25519 \ > >> childsa enc aes-256-gcm \ > >> group sntrup761x25519 \ > >> srcid $self_ip lifetime 1200 tag "IPSEC" > >> ... > >> > >> There is similar $telekom_ip0, $telekom_ip2, and $telekom_ip3 as they are > >> pooled by 4 different /10's and alternate. This is a working config. With > >> sec(4) it breaks though (even with the added iface sec0). > >> > >> In the above config paste the $telekom_ip1 is 87.128.0.0/10 and the > >> $self_ip > >> is self explanatory (it's the IP of the VPS). > >> > >> Is something like this already on a TODO somewhere? Or is there a trick or > >> hint that I can get how to make this work with dynamic IP's with sec(4)? > >> > >> Otherwise my proposal should be considered, and if nothings done by autumn > >> I can perhaps look into that. > >> > >> Best Regards, > >> -pjp > >> > >> Peter J. Philipp > >> " > >> Would a draft to have sntrup761 be good for documenting this choice of > >> hybrid ? > >> > >> Kind regards, > >> //Logan > > > > _______________________________________________ > > IPsec mailing list -- ipsec@ietf.org > > To unsubscribe send an email to ipsec-le...@ietf.org > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
