> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Tero Kivinen > Sent: Tuesday, April 02, 2013 9:06 AM > To: [email protected] > Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 > > The section 2.5 says: > > ---------------------------------------------------------------------- > 2.5. Protocol Behavior > > The recipient of a DH public key that fails one of the above tests > can assume that the sender either is truly malicious or else it has a > bug in its implementation. The recipient MAY respond with an > unauthenticated INVALID_SYNTAX notification, and MUST immediately > drop the IKE SA. > ---------------------------------------------------------------------- > > I think the "MUST immediately drop the IKE SA" is wrong. > > I.e if initiator sends IKE_SA_INIT request out as follows: > > Initiator Responder > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni --> > > > and the responder gets it and starts to generate proper respond message > (i.e. starts to do Diffie-Hellman generate), but while it is doing it > attacker M > sends faked message back: > > <-- HDR, SAr1, KEr*, Nr, [CERTREQ] > > where the KEr* is generated so that it will fail the tests (i.e. > sending all 0xffff...fff as KEr, which would fail the 1 < r < p-1 check), then > using current text the Initiator deletes the IKE SA. When the Responder is > ready with properly generated KEr, it will send its > reply: > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > but it is too late, as Initiator has already "immediately dropped the IKE SA".
How is that behavior fundamentally different from the behavior we would get if the attacker inserted a valid, but different KEr* payload? In that case, the tests will pass, and we'll perform the DH, and come up with incorrect SKEYSEED. If the real responder will then send the correct "HDR, SAr1, KEr, Nr, [CERTREQ]", well, the initiator has already received its response and generated some SKEYSEEDs. I wasn't aware that it was a requirement that the initiator create multiple SKEYSEEDs if it happens to receive multiple initial exchange 2 messages. For an attacker's point of view, the behavior he gets by sending valid KEr* payloads is even more advantageous; he has not only prevented the SA from being created, he also forced the initiator to do more work before doing so. > > Also these tests might also fail during the CREATE_CHILD_SA exchange. There isn't a real requirement to discard the parent IKE SA; of course, we can't allow the creation of the child SA. > > I think the more appropriate text would be to say: While I don't think the below text is wrong (except I would point out that there is no security requirement to discard the parent IKE SA during a test failure while generating a child SA), I would also point out that these don't appear to have any advantage over the current text. > > ---------------------------------------------------------------------- > 2.5. Protocol Behavior > > The recipient of a DH public key that fails one of the above tests > can assume that the sender either is truly malicious or else it has a > bug in its implementation. > > If this error happens during the IKE_SA_INIT exchange, then the > recipient MUST drop the message containing invalid KE payload. If > the invalid KE payload was in the IKE_SA_INIT request, then > responder receiving it MAY send INVALID_SYNTAX error back, but it > MUST NOT start creating any new IKE SA based on such request. If > the invalid KE payload was in the IKE_SA_INIT reply, then Initiator > receiving that reply, ignores the message, and continues waiting > for later messages containing properly formatted KE payload. > > If the invalid KE payload happen during the CREATE_CHILD_SA > exchange (or any other exchange after the IKE SA connection has > been authenticated) and the invalid KE payload is in the request > message, then responder MUST reply with INVALID_SYNTAX error notify > and drop the IKE SA. If the invalid KE payload is in the reply > message, then initiator getting this reply message MUST immediately > delete the IKE SA by sending IKE SA delete notification (as an new > exchange). > > ---------------------------------------------------------------------- > > This also requires some changes to the section 3.3, i.e. replace > > ---------------------------------------------------------------------- > The behavior recommended in Section 2.5 is in line with generic error > treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. > The sender is not required to send back an error notification, and > the recipient cannot depend on this notification because it is > unauthenticated. Thus, the notification is only useful to debug > implementation errors. > ... > ---------------------------------------------------------------------- > > with > > ---------------------------------------------------------------------- > The behavior recommended in Section 2.5 is in line with generic > error treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of > [RFC5996]. The sender is not required to send back an error > notification, and the recipient cannot depend on this notification > because it is unauthenticated. Thus, the notification is only > useful to debug implementation errors. Also the Initiator getting > reply message back with invalid KE payload should simply drop it as > it can be from attacker, and wait for the real peer to reply. > > If the error happens after the peers have been authenticated we do > have a trusted channel to send the errors. In that case we want to > tear down the IKE SA as this kind of failures indicate there is > something seriously wrong with the other peer, and clearing the IKE > SA and starting from the beginning might help. If it is the > responder failing these tests, it can simply return the fatal error > notify (INVALID_SYNTAX, see Section 2.21.3 of RFC5996) and both > peers will delete the IKE SA. The Initiator does not have this > option, as when he notices this problem the exchange is already > done. It needs to start new exchange to delete IKE SA. This IKE SA > clearing is mandatory as Initiator cannot create the Child SA based > on the invalid KE data, and other end already created it as it sent > its reply, thus Child SA state is out of sync. Most compatible way > to delete IKE SA is to just send IKE SA delete notification, even > though starting new INFORMATIONAL exchange and sending > INVALID_SYNTAX notify could also work. > ... > -- > [email protected] > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
