I started editting the draft to incorporate this change, and I ran into a conflict with another part of the protocol: incremental rollout. I'd like some quick advice about how to deal with the conflict.
Here's the feature it's in conflict with: in order to support 'brown-field' deployments (that is, an existing IKE infrastructure that people will be deploying this to), the current draft specifically allows an IKE implementation to be in a state where it works both with peers that implement this, and peers that do not; the idea being that the administrator would first upgrade all their nodes to work in this special intermediate mode; and once they've done they, they then upgrade their nodes to 'do QR-only' mode. This is twice as much work for the administrators; however at no point of time is any network blockage (as two peers will always be able to negotiate). Currently, whether we're using a PPK is negotiated by the N(PPK_NOTIFY) notifies that is sent in the first encrypted message; the responder learns whether or not the initiator supports this draft (and has a PPK) by whether the notify is there. However, that same encrypted message includes the AUTH payload; which is generated using the SK_pi. And, if the initiator isn't sure if we're using the PPK, it wouldn't know whether to use SK_pi' or prf(PPK, SK_pi') Some obvious ways to address this: - Move the notifies to the prior messages (that is, in the clear). If we do this, then by the time we derive keys, we know whether we're using a PPK (even if the responder doesn't know which one it is until it hears the initiator's id). This would mean that anyone could tell whether the two sides are using a PPK - Drop this intermediate mode; that is, make it determanistic to whether we're uisng the PPK (based on the peer identity). This would make roll-out more challenging, but it would simplify the implementations. - For the initiator's AUTH payload, use SK_pi' always. However, I suspect this would partially mess up the reason we're strirring it into SK_pi in the first place. Opinions? Does any other options come to mind? > -----Original Message----- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen > Sent: Wednesday, March 29, 2017 7:11 PM > To: ipsec@ietf.org > Subject: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > So I have proposed earlier that we should mix the ppk to SK_d, SK_pi, and > SK_pr, i.e., something like this: > > SKEYSEED = prf(Ni | Nr, g^ir) > > {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) > > If no PPK available, then > > SK_d = SK_d' > SK_pi = SK_pi' > SK_pr = SK_pr' > > If PPK is available then > > SK_d = prf(PPK, SK_d') > SK_pi = prf(PPK, SK_pi') > SK_pr = prf(PPK, SK_pr') > > This has the follolowing benefits. The SK_d modification will mean that IKEv2 > SA will gain protection against Quantum Resistance after the IKEv2 SA irs > rekeyed, as rekeyed SA will be using SK_d to derive new keys. SK_d also > used to derive the KEYMAT, meaning the Child SA will gain protection. > > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > IKEv2 authentication will fail, and we will get exactly same failure for wrong > PPK than we do with wrong shared key or digital signature failures. This > means that attacker do not gain any information which part of the > authentication failed. > > I do so that in the early cases the PPKs are going to be configured manually > in > the system and there is quite big propability they being wrong, and catching > the misconfigurations with proper error code is better, than just getting the > random garbage on the Child SA data. > -- > kivi...@iki.fi > > _______________________________________________ > 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
