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

[Yoav Nir <[e-mail]>]

On Oct 9, 2013, at 2:10 PM, Tero Kivinen <[e-mail]> wrote:

> 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. 

Deleting the old IKE SA is fine, as we're only transferring the child SAs when we're ready to delete the old IKE SA. See section 3. NO_PROPOSAL_CHOSEN is specifically about crypto-suites, so I wouldn't use that. Perhaps INVALID_IKE_SPI, because that IKE SPI in the notify payload is invalid. But INVALID_IKE_SPI in RFC 5996 is specifically supposed to be outside of IKE, and refers to the IKE SPI field of the packet, not the data field of a notification payload. So either we need a specific error notification, or decide to send no notification. If the responder does not repeat the notification, the child SAs are not transferred. The initiator is not told whether this was because of mismatched identities, a policy issue or some other reason, but I'm not sure that is really needed. 

> 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.

I agree that the data is superfluous, but it's easier for implementations to have just one variant of this message.

> 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…

There are some VPN products that export the IP<-->User identity mapping to other network devices such as firewalls, servers and routers. Even without this, if one peer can "transfer" the SA to the IKE SA of another peer, the original owner still has the keys (so old peer can use the SA, while new peer cannot, despite the "transfer"). All actions done by the old peer now, will be logged as if they had been done by the new peer.

Yoav