Re: does mobike support end-to-end use of tunnel mode?

Erik Nordmark wrote:
> 
> [email protected] wrote:
> 
> > Well... if you have host-to-host tunnel mode IPsec working in a 
> > secure manner, MOBIKE could work as well. But this situation 
> > is pretty rare.
> 
> Clarifying question: for this case are you assuming that the 
> inner and outer IP addresses for the tunnel must be different?
> 
> I think tunnel mode can be used (per the RFCs even if
> implementations might not handle it) where the inner and outer 
> IP addresses are the same.

Yes, both addresses can be the same, but that does not really
change the situation much.

> If you apply MOBIKE to such a case, then you end up with an unsolved
> address ownership issues, because the existence of the IPsec SAs,
> which now use a different outer remote address, will prevent a
> different host which has "inherited" that outer address from
> establishing a SA with the same peer.

The address ownership issue is not new to MOBIKE; exactly the same
thing exists in RFC 4301 and 4306.

> This end-to-end tunnel case was in fact the one that made me
> concerned.
>
> A host is using some public-access network infrastructure. It 
> gets allocated IP address B by a DHCP server.
> 
> B contacts server A (www.example.com), and uses Mobike.
> As a result of this, A ends up with a (IKE and IPsec) SAs that make 
> packets destined to IP address B be subject to the IPsec SA that was 
> setup. Thus packets destined from A to B are placed on an ESP tunnel, 
> with a destination of B.

No; it's much more likely that creating the IPsec SA will fail.

As explained in Section 4.4.3 of RFC4301, server A will allow creating
this IPsec SA _only_if the Child SA Authorization Data in its PAD has
an entry "Authenticated-identity-X is allowed to create IPsec SAs with
traffic selectors matching address B".

In reality, this will not be the case, since server A has never heard
about address B before.

In other words, just sending IKEv2 packets using some particular
address does not imply a permission to create IPsec SAs with that
address in the traffic selectors!  Of course, you can configure
your PAD in a way that allows any authenticated peer to create 
IPsec SAs with any traffic selectors, but that would not be very
secure in most environments.

MOBIKE does not change this part of IPsec.  In particular, moving to
some particular address using UPDATE_SA_ADDRESSES, completing a return
routability check, or including an address in the list of additional
addresses do not imply any updates to the Child SA Authorization Data
in the PAD.

Let's not forget that the "UPDATE_SA_ADDRESSES" part of MOBIKE is
basically an optimization to avoid creating new IKE_SAs when addresses
change (and we want this optimization because creating an IKE_SA is 
likely to require user interaction, not because of extra roundtrips). 
If the PAD says "everything goes", an attacker can get the same effect 
by creating a new IKE_SA and new CHILD_SAs, without using MOBIKE at all.

Presumably, the attacker wouldn't be worried about the inconvenience 
of typing the password twice.

> The host (B) later moves to a different network, where it is
> assigned IP address C. It uses Mobike to move the IKE and IPsec SAs
> from using B to using C. This (and here is were the document is
> silent) means that packets sent from A to B and placed in an ESP
> tunnel with a destination of C. (In any case, there isn't any text 
> I could find that says that there is no residual IKE or IPsec SA or
> policy that refer to B.)

Yes, this is what happens (but only if the PAD allowed creating the 
SA in the first place). And this is correct, since according to
server A's PAD, the peer is authorized to "represent" address B
(there's no distinction between a host and extremely small security 
gateway in this case; although for SG, it's likely that instead
of a B1.B2.B3.B4/32 this would be at least /29 or /28).

> What happens when another host appears on the initial public-access
> infrastructure and is assigned IP address B by the DHCP server?
> (This could be hours or days after the first host left.)  When that
> host tries to contact www.example.com, things would fail due to the
> SADB and SPD entries that were created by the original host.

Creating the IPsec SAs could be succesful only if the PAD also has an
entry "second-authenticated-identity is allowed to create IPsec SAs
with traffic selectors matching address B".  In other words, server A
is configured in a way that both the first and second authenticated
peers are allowed to represent address B.

> The above isn't an issue for a IPsec SG that has static
> allocation/authorization of the inner IP addresses (having a fixed
> binding between the clients CERT and the inner IP address is clearly
> secure). Don't know if there are issues with IPsec SGs that do
> dynamic allocation of the inner IP address.

Dynamic allocation of the inner IP address (using configuration
payloads) basically implies that the SG adds a temporary PAD entry
binding the authenticated peer identity and the newly allocated 
inner address.

Best regards,
Pasi