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: 1. 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. 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://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]
