[IPsec] Comments to draft-nir-ipsecme-cafr-02

[Tero Kivinen <[e-mail]>]

In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the
document lists operations which needs to be done when handling the
notification. The process seems otherwise quite good, expect the error
handling seems to be bit drastic.

It currently says that if the authenticated identites are different
then other end replies with INVALID_SYNTAX error message:

----------------------------------------------------------------------
2.2.  Verifying the HAND_OVER_CHILD_SAS Notification
...
   o  The authenticated identities of both sides under the new IKE SA
      are the same as those under the old IKE SA.  If the authenticated
      identity of one peer differs from the authenticated identity that
      it had in the previous IKE SA, the other side MUST respond with an
      INVALID_SYNTAX notification.
...
----------------------------------------------------------------------

>From RFC5996, the INVALID_SYNTAX processing is described as following:

----------------------------------------------------------------------
2.21.3.  Error Handling after IKE SA is Authenticated
...
   If a peer parsing a request notices that it is badly formatted (after
   it has passed the message authentication code checks and window
   checks) and it returns an INVALID_SYNTAX notification, then this
   error notification is considered fatal in both peers, meaning that
   the IKE SA is deleted without needing an explicit Delete payload.
----------------------------------------------------------------------

I.e. the INVALID_SYNTAX notification is considered fatal in both
peers, meaning that IKE SA is deleted. In this case this will cause
the OLD IKE SA to be deleted. I do not think we want to be that to
happen. Perhaps something less fatal error message would be better as
this is not error cases listed in the RFC5996: "message that was
received was invalid because some type, length, or value was out of
range or because the request was rejected for policy reasons." (Ok, it
could be considered to be rejected because policy reasons).

As we are moving CHILD SAs, perhaps we could consider this as normal
"Generic Child SA error" and use NO_PROPOSAL_CHOSEN. 

Also in the end of the section 2.2 it says:

----------------------------------------------------------------------
   If the Initiator has sent the notification, but the notification from
   the Responder does not match the IKE SPIs in the Initiator's
   notification, the Initiator MUST send a SYNTAX_ERROR notification and
   MUST NOT transfer the Child SAs.
----------------------------------------------------------------------

but there is no SYNTAX_ERROR error message in the IKEv2. This on the
other hand is clearly fatal error, as it indicates that the responder
has somehow corrupted its state, or there is implementation bug there,
if it cannot copy SPI from the request to the reply properly. On the
other hand I see no reason why the reply should include the SPI it
all. It would be better that initiator just sends the notify with the
SPI, and responder replies with the notify and does not include SPI at
all (i.e. its notify data would be empty). The SPI in the responder
message does not have any meaning or use.

In section 7 Security Considerations I can see the attack that can
happen if the authenticated identities are not same. I.e. if host uses
authenticated identities also outside the IPsec. For example the host
might export the authenticated identities to the nfs-server, and
nfs-server could use that to verify what kind of operations the user
can do. In that case attacker might create IKE SA and Child SA to
nfs-server of the server, and then move the Child SA to another users
IKE SA, and then start doing nfs-requests. Now when nfs-server asks
from the IPsec engine who is on the other end of the protected IPsec
tunnel the IPsec engine would respond wrong users...

As long as the IPsec is mostly used for VPNs this kind of setups are
not used, but if host to host IPsec ever comes reality this kind of
setups might happen, so I think that check is very important...
-- 
[e-mail]