It is a pity if QC protection mechanism won't work for these IKEv2
variants (as in your proposal).
It wont. They are separate protocols, and they need to specify how
they are going to make their protocol QC resistant.
Which has nothing to do with this discussion, as G-IKEv2 is not IKEv2,
nor it is work that is done in the IPsecME Wg at all. There used to be
separate working group (Msec) working on those protocols, and their
protocols were based on the IKE, but not really IKE. If they want to
use things we define here they need to incorporate them to their
protocols separately.
We disagree on this. I think that if some solution can be re-used in
a similar protocol, then it saves a lot of unnecessary work.
G-IKEv2 is based on IKEv2 and they are very similar. Not only framing,
but also the core crypto formulas are the same.
Please, re-read the draft. In the last version it is not tied with any
particular algorithms (AES, SHA256) and uses the negotiated
PRF for SKEYSEED calculation.
From the draft:
...
The PPK Indicator Algorithm is a 4 byte word that states which PPK
indicator to use. That is, it gives the encoding format for the PPK
that should be used is given to the responder. At present, the only
assigned encoding is 0x00000001, which indicates that AES256_SHA256
will be used (as explained below).
...
This text is not concerned with SKEYSEED calculation, where the negotiated
PRF is used.
That is actual real reason to do things differently. I.e. perhaps the
KEYMAT generation then should be
KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr))
instead?
That's exactly how PPK is used in the draft (except that
it is used there for SKEYSEED calculation).
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
