Valery Smyslov writes: > > > For this reason RFC8019 advises to make every cookie different > > > or at least to change the secret frequently. > > > > I think adding timestamp is better solution. > > Yes, that's what RFC8019 advises. However, this would make > the problem with false failed authentication worse, since > even without changing secret cookies will change frequently > for the same peer and the chances for this situation to happen will increase.
Combined with initiator sending the cookie it used in the IKE_SA_INIT in IKE_AUTH solves that problem, and puzzles solve part of the problem and the timestamp in cookies solves the saved cookies/puzzles problem. > > Because of the cookie is not anything responder ever used, the > > authentication will anyways fail, as responder will not be using same > > cookie when calculating auth payload than initiator. This is just to > > make sure we do not fail with AUTHENTICATION_FAILED but with some > > other error message the indicates more clearly that something wierd > > happened, and you should try again. > > OK, and that's the problem:. you drop the connection that otherwise > would succeed just because cookie is stall. Sure, the initiator will retry, > but overall it looks like a non-optimal protocol design. If initiator sent cookie we do not recognize, that means it is an attacker, or broken implementation so most likely the authentication would not work anyways, so no we are not throwing out connection that would work. Cookie time will tell whether the cookie is new enough that we should recognize and if cookie time is so old that our policy does not allow us to accept it, then accepting that cookie is forbidden by policy. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
