> > > > 1. Nonces. > > > > > > > > The draft specifies that each additional key exchange performed > > > > over IKE_AUX includes new nonces. My question - why nonces > > exchanged > > > > during IKE_SA_INIT cannot be used instead? Is it critical for > > > > security? > > > > > > No, it is not. Instead, we were (mostly) reusing the format of the > > > CREATE_CHILD_SA request; as that request already had nonces, we saw no > > specific reason to remove them. > > Correction to what I said: the original reasoning was not to keep the IKE > message format, but rather to reuse > the IKE child SA key derivation function (section 2.17)
That's how I understood it. > > It's true that AUX_I (f collision resistant PRF of initiator's IKE_AUX > > messages) > > is included in the initiator's signature. > > My concern is: from my recollection of SIGMA paper it is essential for > > security > > that each party includes its peer's nonce in the signature. In case of IKE > > initiator, the NonceRData is responder's nonce (from IKE_SA_INIT) and it is > > included. > > But the AUX_I contains only PRF over initiator's messages, i.e. it contains > > only > > initiator's additional nonces, not responder's ones. > > Is it OK for authentication that we don't include peer's additional nonces > > in > > the signature? Won't we screw up SIGMA? > > (Disclaimer: I'm not a cryptographer). > > The nonces are included; however instead of including the text of the nonce > directly, we're including a > complex function of (among other things) the nonces. If you change the > nonces, you change the output of > that complex function, which changes the text of what is signed, and that is > what SIGMA relies on. Sorry for being tedious, I just want to eliminate all possible misunderstanding. I understand that the nonces exchanged in IKE_AUX are included through complex function. My concern is about which nonces are included in signature. From my recollection of SIGMA each party must sign (among other things, e.g. his MACed ID) his peer's nonce. I.e., initiator must sign responder's nonce and responder must sign initiator's nonce. With nonces exchanged in IKE_AUX this is not true, each party signs his own nonces sent in IKE_AUX, not peer's ones. So, the initiator still signs responder's nonce received in IKE_SA_INIT but signs only his own nonces that he sent in IKE_AUX exchanges (implicitly, by including AUX_I which is PRF over initiator's IKE_AUX messages). The same for responder. So my concern is - is it OK that each party only signs his peer's nonce from IKE_SA_NIT and doesn't sign his peer's nonces from IKE_AUX, signing his own nonces instead? > > My understanding is that the crypto world is now trying to migrate to > > quantum-safe crypto (including key exchange). > > The problem is that now we don't have quantum safe key exchange > > methods that are fully trusted by cryptographers and have acceptable > > performance and public key size. For that reason we want to bundle several > > key exchange methods and for this purpose we need to invent that things > > like IKE_AUX. But I hope that in a future cryptographers will eventually > > invent > > key exchange methods that will be fully trusted and have acceptable key > > size, and these methods will be so good, that can even replace classic > > (EC)DH. > > If that happen, all sophisticated games with IKE_AUX will become > > unnecessary and we can come back to a single key exchange in IKE_SA_INIT > > using these new methods... So I meant that only such methods should be > > added to Transform Type 4. > > Given that we don't know which such methods would eventually meet this final > criteria of "usable only by > itself", I would expect that we would be well advised to include everything > on the list. Even in cases of > methods with moderately large key shares (e.g. Frodo), there are times that > IKE doesn't care about > fragmentation (e.g. TCP encaps), and in those cases, it might very well be > considered a viable option by itself. OK, this makes sense. > In addition, you essentially gave two proposals; one where transform type 6 > meant "Lattice Based", and > another proposal where transform type 6 meant "whatever key exchange we're > doing in the first IKE AUX > exchange". > > Of those two proposals, I would personally vote for the second one; it would > appear to me to be cleaner (of > course, I would still prefer the tjhai proposal to either...) The second one was my preference too. > > > Why not make them all a possible transform id for type 4? After all, > > > there are scenarios where fragmentation is not an issue (e.g. TCP > > > encaps) > > > > Since responder can return only a single transform of each type, this would > > mean that we cannot bundle several key exchanges unless new Transform > > Types are defined. > > > > Or do you mean that we still define new Transform Types, but make all new > > key exchanges available in Transform Type 4 too for the cases where > > fragmentation is not an issue and we don't need classic (EC)DH? > > The latter (still define new Transform Types, but also make all new key > exchanges available); I see no specific > reason to restrict things unnecessarily... I agree. > > Using attributes will make definition of Transform ID clearer, but, as Tero > > pointed out, it won't help negotiation. > > But using attributes instead of defining a large number of Transform IDs for > > all possible combination of parameters looks like a good idea - at least > > we'll > > save a few bytes on the wire and a lot of lines on IANA registry page :-) > > Actually, I believe using attributes (rather than distinct transform ids) > would add to the payload size (but only > slightly). For example, instead of: > > +-- Transform D-H ( Name = NTRU_3 ) > > We might have > > +-- Transform D-H ( Name = NTRU ) > +-- Attribute ( Security Level = 3 ) It seems that you are right here and I was wrong. I was thinking of situation when attributes can define ranges, in which case we could save some space in some situations, but it is not possible now. > > Do I get you right that the idea is to negotiate several successive SAs with > > unmodified CREATE_CHILD_SA, each with different (QS)KE methods, so that > > the resulting SA absorbs entropy from all the exchanges? > > That could work for IKE SA (rekeying), but I fail to understand how it will > > work > > for Child SAs. If you want to create new or rekey existing Child SA with > > additional entropy, then you cannot perform successive key exchanges > > unless you somehow modify CREATE_CHILD_SA exchange. Did I miss > > something? > > Actually, the original idea was cruder than that; suppose you wanted to rekey > an IPsec SA, and you used three > key exchange methods. What you would do is: > > - First create a child IKE SA (using keying mechanism 1); this would replace > the original IKE SA > - Then, create a second child IKE SA (using keying mechanism 2); this would > replace IKE SA that you just > created > - Finally, create children IPsec SAs (using keying mechanism 3) > > As I said earlier, I could certainly understand it if the WG decided that > this was unacceptable... Well, this essentially means that any need to create or rekey Child SA with additional entropy will require several successive rekeys of IKE SA. How policy will be negotiated in this case? In IKE_SA_INIT initiator proposes all KE methods at once and responder selects an appropriate combination. In your proposal initiator proposes them one by one, so that responder don't have whole picture. You can argue, that policy should non change in case of rekey, but if you create a new Child SA for with different selectors you would probably want to create it with different policy, than IKE SA and previous Child SAs... I also suspect some complications with simultaneous rekeying... Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
