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