Hi Ben, > On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote: > > > > > Roman Danyliw has entered the following ballot position for > > > draft-ietf-ipsecme-qr-ikev2-10: No Objection > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > [...] > > > > > -- Recommend explaining the notation/relationship between the “prime > > > versions” > > > of the sub-keys (i.e., SK_d’ and SK_pi’ and SK_pr’) in the this SKEYSEED > > > formula with the SKEYSEED formula in Section 2.14 of [RFC72196]. > > > > I'm not sure I fully understand what you mean. > > I think we provide formulas of how prime and non-prime versions > > are correlated (i.e. how non-prime versions are computed from prime > versions). > > Am I missing something? > > I think the idea is something in the general vicinity of "the un-primed > values SK_d, SK_pi, and SK_pr are used as inputs to subsequent steps of the > IKEv2 exchange; this document uses the primed versions to represent the > output of prf+ that are used directly in regular IKEv2, in order to > introduce an additional operation (combination with PPK) between prf+ and > subsequant usage". A reader looking at this document and RFC 7296 > side-by-side will see that where RFC 7296 sets {SK_d [...]} = prf+ > (SKEYSEED, [...]), this document uses the "primed" versions, and might > wonder what's different between SK_d (RFC 7296) and SK_d' (this > document).
Thank you for clarification, we'll add similar clarification to the draft. Regards, Valery. > -Ben _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec