Scott Fluhrer (sfluhrer) writes: > o There is the option listed in the draft, where we modify both the KEYMAT > and SKEYSEED computations; stirring it into the KEYMAT implies that the IPsec > SAs are generated with QR-resistant keying material, while stirring it into > the SKEYSEED implies that any child IKE SAs implies that any IKE SA (other > than the initial one) also has QR-resistant keying material. This latter was > done specifically so that an implementation can have protected IKE SAs (by > negotiating a child SA immediately) > > o Dan Harkins suggested that we modify only the KEYMAT. This is a simpler > option, and will continue to protect the IPsec SAs; however this implies that > any data protected by the IKE SA could potentially be recovered by a Quantum > Computer.
This has the issue that differences in the PPK will not be detected, i.e., if PPKs are mismatched because of configuration error, we do get IKEv2 SA up and running, and we create IPsec Child SAs without errors, but then all traffic in IPsec SA will simply be dropped as the keying material is wrong. Also this does not protect IKE SAs at all. > o Valery Smyslov gave a suggestion that we instead stir in the PPK into the > initial SK_d; as all keying material is generated based on that, this would > also mean that IPsec SAs and any child IKE SAs are also protected. This also > means that an implementation would not need to remember the PPK after the > initial negotiation. The only downside I can see is that we would have to be > a bit careful about when we update the SK_d (obviously, before we actually use > it). This would provide protection for the IPsec SAs and Child IKE SA (i.e. IKE SAs after rekey). It still has same issue that we do not get verification that PPKs are same. > To me, all three strike me as reasonable ideas (unless we decide that we will > need to protect the real identity data encrypted via the IKE SA; in that case, > Dan’s idea doesn’t protect that). Can I get opinions as to which strikes the > group as the best? Are there any fourth options that people would want to put > on the table? I would propose that we add PPK to both SK_d and SK_pi and SK_pr. SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs. The SK_pi and SK_pr provides key verification, meaning that incorrect PPKs will result AUTHENTICATION_FAILURE notification, instead of just wrong keys. SK_pi and SK_pr as used to MAC the ID payloads of the peers, and if we mix PPK in there that might also provide some resistance against quantum computers even when the attackers can break RSA. I.e., it does not matter that they can generate valid signatures if they do not know what they are supposed to sign. > In both cases, the traffic that is protected by the initial IKE SA can be > recovered; that’s because that traffic is encrypted by the initial SK_ei, > SK_er keys, and those would be recoverable. The important thing is to keep the SK_e*/SK_a* so they do not depend on the PPK. The problem with them is that if they depend on the PPK, then we cannot see contents of the packet before we need PPK, so PPK negotiation needs to happen in clear before IKE_AUTH. SK_d, SK_pi, and SK_pr all benefit from PPK, and they can and should use get PPK mixed in to them. I.e., define SK_d' = prf(PPK, SK_d) SK_pi' = prf(PPK, SK_pi) SK_pr' = prf(PPK, SK_pr) and change uses of SK_d, SK_pi and SK_pr to use those. > - The second item is anonymity; some people were interested in > preserving anonymity (however, not at the expense of excessive complexity). > One idea that was brought up was that the initial exchange would be done using > pseudonyms (which would be sufficient for the responder to identity the PPK), > and then once initial IKE SAs have been established (in a QR form), exchange > the real identities. My questions: > > o Would this idea of pseudonyms actually give any real identity protection? > Wouldn’t that assume that several initiators use the same PPK (so they could > use the same pseudonym)? Is that the sort of thing we should be encouraging? > > o Should this be addressed in this draft, or could it be addressed in a > follow-up draft? I think we can do that in follow up draft, and I so there is no need to complicate things in this draft. > o If it would be addressed in a follow-up, would any hooks be required? For > example, would we want to introduce an opaque bit in a notify message to > indicate this? As I see the pseudonym support, we only need a way to get quantum resistant IKE SA, and Child IKE SA is fine for that, so we already have all the features need. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
