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".
Also these tests might also fail during the CREATE_CHILD_SA
exchange.
I think the more appropriate text would be to say:
----------------------------------------------------------------------
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
