Hi!
> -----Original Message-----
> From: Benjamin Kaduk <ka...@mit.edu>
> Sent: Monday, January 13, 2020 12:58 PM
> To: Valery Smyslov <smyslov.i...@gmail.com>
> Cc: Roman Danyliw <r...@cert.org>; 'The IESG' <i...@ietf.org>;
> ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; draft-
> ietf-ipsecme-qr-ik...@ietf.org
> Subject: Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-
> ikev2-10: (with COMMENT)
>
> 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).
Yes. That's the kind of clarifying language I think would help. It's not that
the formula isn't self-consistent to this draft. It's that when this document
says compute a "standard IKEv2 key derivation" and then "a reader looking at
this document and RFC7296 ... might wonder what's the difference ..." (as Ben
said).
Thanks,
Roman
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
