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

[Tero Kivinen <[e-mail]>]

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

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.

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

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. 

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

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."
-- 
[e-mail]