Hi Steffen, Yes, an update to G-IKEv2 will be necessary.
Thanks, Brian > On Mar 11, 2026, at 1:38 PM, Fries, Steffen <[email protected]> wrote: > > Hi Brian, > > Thank you for the prompt reply. This certainly helps in going forward. > > Regarding GDOI maintenance, I understood that we have to define the > extensions, which have been defined in RFC 8052, for G-IKEv2 to participate > in the PQC update of the base key establishment (IKEv2). > > Best regards > Steffen > > From: Brian Weis <[email protected]> > Sent: Wednesday, March 11, 2026 7:47 PM > To: Fries, Steffen (FT RPD CST) <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: Implementation questions to GDOI (RFC 6407) and implicitly IKEv1 > > Hi Steffen, > > Some information is embedded below. > > On Mar 9, 2026, at 3:06 AM, Fries, Steffen <[email protected]> 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: > > Interpretation of nonces to be included in the hash calculation in > GROUPKEY-PULL exchanges as outlined > inhttps://datatracker.ietf.org/doc/html/rfc6407#section-3.2 > 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://datatracker.ietf.org/doc/html/rfc2409#section-5.5). > 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. > > RFC 6407 GROUPKEY-PULL exchanges are indeed intended to align with RFC 2409. > As such, the “_b” is interpreted as “the body of the payload”, just as RFC > 2409 specifies. > > I no longer have access to commercial implementations, but I did also verify > this as being the case in an old reference implementation, which did > interoperate with at least one early commercial implementation. > > > 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://datatracker.ietf.org/doc/html/rfc6407#section-3.2) and references > RFC 2409 regarding the signatures. > RFC 2409, section 5.1 > (https://datatracker.ietf.org/doc/html/rfc2409#section-5.1) 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. > > Section 5.3.6 of RFC 6407 defines the requirements for generating signatures > included in the GROUPKEY-PUSH exchange SIG payload, and there is a specific > GDOI namespace for the algorithms that are used with this field. This section > should have been clear in defining for each supported algorithm. > > However, I agree that the RSA definition is murky. The reference to "the > EMSA-PKCS1-v1_5 encoding method” in RFC 3447 does clearly state that the OID > should be included, but after checking the reference implementation I believe > intent was simply to specify the PKCS 1.5 padding for the signature, not > implement the entire encoding method. The reference implementation uses the > (now deprecated) OpenSSL RSA_private_encrypt() function to create an RSA > signature for the GROUPKEY-PUSH exchange, which takes as input the hashed > message and simply signs it using the specified padding. The implementation > hashes the message itself and does not include the OID before sending it to > RSA_private_encrypt(). I believe this interoperated with the commercial > implementation. > > To the best of my recollection, this was also done to have symmetry with the > RFC 2409 signing process. As in the case of RFC 2409 the hash algorithm is > negotiated and thus known in advance and embedding the OID is not needed. > > I hope that’s clearer. > > Thanks, > Brian > > > 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]
