Valery Smyslov writes: > > 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.
But as you pointed out key distribution and generation are not same. Yes, the method we define here should be easily re-used in there, but it still do require some work, and that is something thta the G-IKEv2 people needs to do. > >> 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. True, but unless you do that you never get to the SKEYSEED calculation, so the above system is needed, to know which PPK is to be used and this is the complication caused by the fact that SK_e depends on the PPK. Of course you can do the same stupid thing that was done on IKEv1, and say that you just use the source IP-address and fetch PPK based on that, but that method simply does not work well. > > 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). And because it is used in the SKEYSEED it means we need to know which PPK is used BEFORE we can decrypt IKE_AUTH, which means that we cannot use identity to pick it. And because of that we need to make complicated method of telling which PPK is used in the IKE_SA_INIT using fixed ciphers that are not implemented on all devices (for example IoT). All this limits the use of this quite a much, which mostly makes this only usable in special cases. I instead want to get good enough protection for current IKEv2 which is very widely usable even when it does leak out identities, traffic selectors and configuration payloads to attacker who can break Diffie-Hellman (or anybody who is willing to do active attack). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
