Hi Toerless, Thank you for the pointer. This is what I was referring to that we are looking into G-IKEv2. The point is that there are implementations available in the power system domain and backward compatibility is an issue. As G-IKEv2 allows to use a different port, we can transition to it in a smooth way.
Best regards Steffen > -----Original Message----- > From: Toerless Eckert <[email protected]> > Sent: Monday, March 9, 2026 11:31 PM > To: Fries, Steffen <[email protected]> > Cc: [email protected]; Brian Weis <[email protected]> > Subject: [IPsec] Re: Implementation questions to GDOI (RFC 6407) and > implicitly > IKEv1 > > Sorry, not deep enough in GDOI anymore to be able to answr your questions.. > > But let me ask you in return: > > > So we are already looking at G-IKEv2 to be future proof. > > Did you check out RFC9838 and does it meet your requirements of future proof > (PQ & friends ?) ? > > Cheers > Toerless > > On Mon, Mar 09, 2026 at 10:06:15AM +0000, Fries, Steffen wrote: > > Hello all, > > > > We are using GDOI (RFC6407) in the power system domain to distribute group > keys to protect domain specific group information exchanges (specified in IEC > 62351-9). We started to adopt it in the standard already back in 2015. We are > aware, that the milage of GDOI may be limited, given the transition to PQC > will > likely not be done, as it bases on IKEv1. So we are already looking at > G-IKEv2 to > be future proof. Nevertheless, we run into questions on GDOI as more > implementors adopting it. > > > > Specifically two questions were raised: > > > > > > 1. Interpretation of nonces to be included in the hash calculation in > GROUPKEY-PULL exchanges as outlined in > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker. > ietf.org%2Fdoc%2Fhtml%2Frfc6407%23section- > 3.2&data=05%7C02%7Csteffen.fries%40siemens.com%7Ca58d6ccd027e405646f > d08de7e2b8c54%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C639086 > 922664271228%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=H28Dqu19uEXD5PzOgbjtzf96lKKZ1L727MEv0NxNMZs > %3D&reserved=0 > > > > * The specification relates to the four messages used in the context of > GROUPKEY-PULL exchange: > > HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) > > HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) > > HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | GAP ]) > > HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD) > > > > * The question relates to the interpretation of Ni and Ni_b. The > > sentence, > which cause the question is: > > > > The GM > > > > expects to find its nonce, Ni, in the HASH of a returned message, and > > > > the GCKS expects to see its nonce, Nr, in the HASH of a returned > > > > message. HASH(2), HASH(3), and HASH(4) also include nonce values > > > > previously passed in the protocol (i.e., Ni or Nr minus the payload > > > > header). > > > > * Based on the parenthesis, one could interpret that Ni is the nonce > > payload > with the header and Ni_b without the header. Another interpretation could be > that > the "_b" indicates the reuse of the nonce for liveliness. As this may result > in > interoperability problems, we wanted to be sure, how it is intended and how > it has > been implemented by others. > > * BTW, as GDOI utilizes IKE, a similar formulation can be found in RFC > > 2409, > section 5.5 > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker > .ietf.org%2Fdoc%2Fhtml%2Frfc2409%23section- > 5.5&data=05%7C02%7Csteffen.fries%40siemens.com%7Ca58d6ccd027e405646f > d08de7e2b8c54%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C639086 > 922664285562%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=WL%2FYqeulcl7uJBjPsOmpr3OHuxAMe1OXpWuET6y > VzWo%3D&reserved=0). Here, the notation section mentions that "_b" is to e > interpreted as "the body of the payload". This may already answer the > question, > also for RFC 6407. > > * Any hint regarding the intended interpretation would be good. I guess > > it > aligns with RFC 2409. > > * Also any hint about existing GDOI implementations and how they do the > interpretation would be important to ensure interoperability. > > > > > > > > 1. Different signature formats in GROUPKEY-PULL and GROUPKEY-PUSH. > > > > * GDOI (RFC 6407) utilizes signatures to protect the GROUPKEY > exchanges. The PULL case is described in section 3.2 > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker > .ietf.org%2Fdoc%2Fhtml%2Frfc6407%23section- > 3.2&data=05%7C02%7Csteffen.fries%40siemens.com%7Ca58d6ccd027e405646f > d08de7e2b8c54%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C639086 > 922664293664%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=qVDX1WoxejoNbEyWPa1Ff3ZkxUtdeUKoJmKJY5jXu9 > U%3D&reserved=0) and references RFC 2409 regarding the signatures. > > * RFC 2409, section 5.1 > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker > .ietf.org%2Fdoc%2Fhtml%2Frfc2409%23section- > 5.1&data=05%7C02%7Csteffen.fries%40siemens.com%7Ca58d6ccd027e405646f > d08de7e2b8c54%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C639086 > 922664301591%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=MD58xfzGBTQGpbXJkoHk%2Fielc455bI8bQHazEcM0 > qFA%3D&reserved=0) at the end provides requirements for the RSA signatures, > and specifically that in the utilized format the OID of the utilized hash > algorithm > MUST be neglected. > > * The GDOI PUSH case does not explicitly provide the reference to the > > SIG > payload of RFC 2409 and this may be interpreted that the format is a standard > signature including the hash OID. > > * The question that was raised is if there was an asymmetry in the > > signature > format intended or if it was assumed to use the same format. > > * Any hint regarding the intended interpretation would be good. > > * Also any hint about existing GDOI implementations and how they do the > interpretation would be important to ensure interoperability. > > > > Thank you in advance for your support. > > > > Bets regards > > Steffen > > > > -- > > Steffen Fries > > Siemens AG > > > > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > -- > --- > [email protected] > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
