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]
