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

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Oct 2013 14:10:31 +0300

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...
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 11 Oct 2013 20:01:31 +0000

> then other end replies with INVALID_SYNTAX error message:

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:

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

> 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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Oct 2013 16:10:43 +0300

Yoav Nir writes:
> 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.

Yes, but usually when you have error cases which might happen in
normal case that kind of fatal processing of the error is bit drastic.
Anyways if you think the deletion of old IKE SA (and all Child SAs in
it, which did not get transferred), then I think it would be better to
explictly mention it here.

I.e. any errors happening during the handing over Child SAs will cause
old IKE SA and all Child SAs to be deleted without explicit delete
notification. 

> NO_PROPOSAL_CHOSEN is specifically about crypto-suites, so I
> wouldn't use that.

NO_PROPOSAL_CHOSEN is also used as "Generic" Child SA error when Child
SA cannot be created for some other reason. When trying to handing
Child SAs from one IKE SA to another, and that fails because Child SAs
cannot be created in the new IKE SA because of the policy reasons
(i.e. not same authenticated identity), I would consider that as case
where Child SA cannot be created, or in this case handed over.

See RFC5996 section 3.10.1 description of NO_PROPOSAL_CHOSEN and the
second last sentence there.

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

INVALID_IKE_SPI cannot be used, it has very specific meanings and we
cannot change that. 

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

That would be one option too, i.e. if no confirmation comes back, then
no SAs were moved.

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

I actually disagree on that. Having two ways of parsing / generating
this message is about same complexity than having one way of parsing /
generating and then special error code checks for checkking that the
useless values sent by the other end are correct. But what is more
complex and what is required by this specification is that the
initiator MUST then be able to initiate completely new informational
exchange and send INVALID_SYNTAX notification which will cause the
both ends to delete the IKE SA.

Currently we have avoided the cases where there is errors happening in
the initiator when he is processing the responders reply, and where he
would need to send separate informational exchange to indicate that.
Note, that there is no way for example the responder to know why the
initiator is sending him that INVALID_SYNTAX message.

Eliminating the data from the reply will also eliminate the useless
checks, and will also eliminate the need to generate new informational
exchanges to send fatal error messages. 

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

Yep, and because of this I think this check is very important, and
should be explained bit more in the draft, i.e. not just say that "we
cannot think of any attack that would exploit this."
-- 
[email-masked]