Michael Richardson writes: > > Tero Kivinen <kivi...@iki.fi> wrote: > > Scott Fluhrer (sfluhrer) writes: > >> Going through this suggestion (and tweaking it a bit): > >> > >> Pluses: - I believe it can be made a bit more flexible than you make > >> it out; it don't believe that you actually need to update every node > >> with every PPK at the start. With this protocol, the initiator > >> decides > > > I did not even require that. I said you need to provide all PPKs for > > that one node at the same time. Or at least that I was trying to say. > > I can now see that my text was bit unclear. > > Why do we need to provide PPKs for all peers at the same time?
Because responder tells that PPK is supported in the IKE_SA_INIT, and then in the IKE_AUTH the initiator will either use PPK or not. If we have responder configured so that it only has some PPKs, i.e., it has PPK for node A, but not for node B, and both of those are nodes which do not have static IP-address, then it does not know whether it should send N(PPK_SUPPORTED) in IKE_SA_INIT. If it sends N(PPK_SUPPORTED) to node B, then node B might use PPK in its IKE_AUTH AUTH payload calculation, and if responder then does not have PPK it will not be able to verify the AUTH payload and IKE_AUTH fails. Of course if responder can know whether it has PPK for the initiator based on the IP-address, then it does not need to have all PPKs for all initiators that might connect to it. Simiarly if it is only acting as iniatitor, it can always decide whether to use PPK or not. But in general case it needs to know the PPKs for all peers that could connect to it using PPK before it can start sending N(PPK_SUPPORTED). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
