> -----Original Message----- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov > Sent: Thursday, January 14, 2016 7:58 AM > To: Scott Fluhrer (sfluhrer); Michael Richardson; ipsec@ietf.org > Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance > > Hi Scott, > > >> Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote: > >> > - It defines the transform of the nonce from the on-the-wire > >> version into the > >> > one presented to the IKEv2 KDF (mixing in the PPK). > >> > >> > - The initiator gives an indication of which PPK to use (without > >> leaking > any > >> > information about it to someone two doesn’t know the value). > >> > >> > For the first use, it would be reasonable to have the initiator > >> define a > >> > bitmask of the algorithms it supports, and the responder to > >> select one > >> > >> That's not very algorithm agile, nor very IKEv2 happy. Don't we > >> already have IANA values for all the algorithms involved? (shouldn't > >> we have them) > > > > The 'bitmask idea' was off the top of my head; we could certainly give > > a list of IANA values (such as the IKEv2 PRF). My chief fear is that > > we don't overengineer this; this really is a "short term solution" > > (with the usual caveat that there are no short term solutions), and > > that a post-quantum DH-like function is the Right Thing (only we > > haven't agreed on that yet). The issue with having a complex > > negotiation process is that may be a lot of rarely executed code, and that > > in > itself may lead to security vulnerabilities. > > Is it possible to use the already negotiated IKEv2 prf inside the modified > crypto formulas? > In this case they would look like: > > SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir) > (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = > prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr) > > and so on. I'm not a cryptographer, but it seems to me that this is safe, > isn't > it? > In this case no additional negotiation is required since prf is negotiated in > IKEv2 anyway and thus we would have algorithm agility in KDF for free.
I like this -- I'm stealing this idea. > > >> > This second use is rather trickier to have agility; it is sent > >> before the > >> > initiator has any contact to the responder. I don’t see how the > >> > responder can > >> > indicate which algorithms it supports (without adding a round trip to > the > >> > protocol). > >> > >> This is why I suggested... if you have to add a round trip anyway... > >> might as well solve a puzzle or something along the way. > > > > One of the constraints that we felt we had to live within was to > > minimize the changes we made to IKEv2, both from a crypto standpoint, > > and from a state machine standpoint. Hence, we decided that adding > > vendor id payloads (or notification payloads) to existing messages we > > OK, however adding additional round trips was out of bounds. > > Note, that IKEv2 state machine has already accomodated the possibility of an > additional round trip in case the initiator has incorrectly guessed the DH > group. Introducing one more condition for additional round trip should not > be too hard, however I agree that it adds some complexity and thus may be > considered inappropriate for a short-term solution. > > However, if no better solution exists I'd prefer to live with a single fixed > crypto primitive, than with two. Is it possible to get rid of AES and to > change > the indication of the ppk to use to something like the following? > > HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes) > > (disclaimer: I'm not a cryptographer) Your proposal is perfectly sound from a cryptography perspective. Actually, the reason we proposed the "entry in the AES codebook" approach, rather than something like the above structure, is due to practical reasons. When the responder receives the hint, he has no idea which ppk the initiator is referring to (and he doesn't know the identity yet); our model is that the responder has a list of ppk's that he knows about, and checks to see if the one that the initiator had is on the list. It'd be nice if there was a way for the responder to search through his databases of known ppk's quickly, however I don't know how to let him do it in sublinear time (without leaking whether two exchanges used the same ppk, which would leak information about the identities). So, what we settled on is to make the linear scan for the right PPK as fast as possible. With our proposed solution, an aggressive responder could have all the AES keys corresponding to the ppk preexpanded, and just check each potential ppk by doing one AES block encryption (or decryption, if they prefer); if the implementation has AES-NI, that is fairly fast. With your proposal, they could preexpand the HMAC keys, but would still need to do two SHA256 compression function evaluations. > > > If one were to add additional round trips, a cleaner solution would be > > to negotiate the initial IKE SA as per the RFC, and then if the two > > sides decide that they need QR, create a child SA (in a PQR manner). > > The current approach has the issue that we need to stir in the > > post-quantum magic before the identities were exchanged (and hence the > > initiator gives the indication of the ppk). If you establish a secure > > connection (and exchange > > identities) first, then it becomes much cleaner (as both sides would > > know who they are talking to, and which ppk they should use). > > However, that was deemed to be too large of an delta. > > I'm not sure this approach is easier than approch with additional round trip. > I understand that it has some advantages (e.g. no need for linear key > search), but from state machine point of view it may appear to be more > complex. It would get rid of the linear scan issue. > > Regards, > Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
