Valery Smyslov writes: > > Thanks for the detailed clarification, and I still disagree... This > > situation is very unlikely with correctly functioning peers, and I don't > > think we should recommend acting on unauthenticated information, even if > > it slightly improves performance. Actually, I think it is a prototypical > > premature optimization. > > What else could we recommend to do in this situation? > If responder deletes IKE SA in case it receives IKE_AUTH > message that doesn't pass ICV check, then it would give > an attacker an easy way to prevent legitimate initiator > to connect - just monitor the network and once IKE_SA_INIT > from the legitimate client is finished, inject IKE_AUTH message > containing garbage.
I suggest we do similar thing we do for IKEv2 in general. I.e. if you get IKE_AUTH message which does not pass ICV, you simply drop it. I would expect most of the implementations do that already. Also before you can verify the ICV you need to know the SK_a and to be able to get that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half of Diffie-Hellman. So at that point you have already calculated the Diffie-Hellman. Also implementation would be completley stupid if it would not store the SKEYSEED and SK_* keys once it has calculated them, so I would expect every implementation do that already, i.e. they will already keep them, and there is no need to say anything about this in here. > If responder keeps half-open IKE SA for a while waiting > for more IKE_AUTH messages, then I see no reason to repeat > calculating D-H shared secret with every received message - > the result will be exacly the same. Why would anybody ever repeat the D-H secret calculation, when they have already calculated SKEYSEED (and SK_*) earlier? Do we also need to say that for future notificaitons it would be nice for implementations to keep the "cached" SK_* values stored in IKE SA, and not to calculate the SK_* from the KE payloads for every single packet? I do not think we need to say such thing, and I do not think we need to say that once you have calculated the SK_* you keep them until you delete the IKE SA. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
