I've been putting together the updates, and one question came up: what format should the PPK_ID field (sent be the initiator in the first encrypted message to identify the PPK it used) be?
I'm thinking that an arbitrary octet string would be appropriate; it can be distributed at the same time as the PPK data itself. In addition, one thing that we do not want to interfer with extensions to this proposal; for example, the discussed extension that pulls the PPKs from a 1G one-time pad file. I believe that concept could work here; in that case, the ID field would be just the PPK index (and both sides would understand that extension). I don't believe that IKE currently makes any assumptions that notification data is a multiple of 4 bytes in length; is that correct? Is there anything I missed? > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Wednesday, April 05, 2017 3:30 PM > To: 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > Ok, I now see what part of your idea I was (sort of) trying to work around. > To > make it clear to everyone, I'll spell out the problem we're trying to address, > and how your idea (with a slight addition on my part) could address it. > > What we're talking about is "how would someone take a network that's using > the standard IKE implementation, and convert it into a network that uses > IKE+PPKs, and in a way that doesn't cause a flag day, or prevent negotiations > from happening between nodes while the upgrade is in progress. > > The idea is that the network admin goes through the nodes, and upgrades > them in order; in step 0, the nodes are running standard IKE, and in the final > step, they are running the full PPK protocol (and insist on using it). For > the > upgrade to be bumpless, we require that any node at step i be able to > communicate (as either initiator or responder) with a node at step i-1, i or > i+1 > (assuming, of course, that our security policy allows those two nodes to > communicate). > > With your idea, there are three steps (and so the admin would update each > node in the network twice): > > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > - Step 1 is "if we're the initiator, then use PPKs if the responder signaled > support for it" > "if we're the responder, then signal support, and allow the use of PPKs" > - Step 2 is "insist on PPKs (and also signal support if we're the responder)" > > > The issue I was pondering was "what if the admin wants to update only part > of their network (say, as a test)?". As I understood your proposal, the > PPK_SUPPORT notify was always on if any PPKs were configured; indeed, > from a responder side, it has to be that (because the responder has no other > context to issue it or not). However, from an initiator standpoint, it knows > who the responder is (or, at least, it has to; it's the one that selects which > PPK to use); hence, from the initiator standpoint, the PPK_SUPPORT notify > could mean "I have a PPK that I would like to use with you, are you willing?" > > With that proviso, then partial upgrades of the network can work; if an > initiator (in the upgraded portion) talks to a responder in an nonupgraded > section (or in an independently upgraded section), it just notes it doesn't > have a PPK, and so doesn't send the notify (and similarly, if it was the > initiator > who wasn't upgraded, the responder performs the standard IKE protocol, > and when the responder gets the identity, it can verify whether or not it > would have expected the initiator to be upgraded). > > > So, how does that sound? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
