> -----Original Message----- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Michael > Richardson > Sent: Wednesday, January 13, 2016 11:59 AM > To: ipsec@ietf.org > Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance > > > 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. > > > 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. 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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
