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

Jari Arkko wrote:
> Erik,
> 
> Here are some text changes that may help clarify applicability
> and the issues relating to the allocation of inner addresses. First
> a new subsection to be added to the security considerations
> section:

Thanks for suggesting text. And sorry for not following up earlier (I 
thought I had done that last week, but I see I didn't finish my email to 
the MOBIKE list.)

>  5.x. Inner Address Ownership
> 
>  MOBIKE ensures that the IKEv2 peer is always the same
>  entity regardless of its changing addresses. These addresses
>  are in the IKEv2 messages as well as outer addresses in
>  IPsec tunnel packets.
> 
>  However, MOBIKE relies entirely on IKEv2 in the use of inner
>  addresses. Typically, the same inner addresses are employed
>  throughout the lifetime of the IKEv2 security association, i.e.,
>  MOBIKE does not modify the inner addresses. Changing the
>  inner address would in often result in a need to re-establish
>  existing transport layer connections, as these are often
>  bound to specific addresses.
> 
>  As with IKEv2, it is necessary to ensure that peers are authorized
>  to use the inner addresses that they negotiate when creating
>  child SAs. The Peer Authorization Database (PAD) specified in
>  RFC 4301 [RFC4301] allows administrators to specify what
>  inner addresses specific IKEv2 peers have. In addition, it
>  is necessary to ensure that the dynamic allocation of addresses
>  through configuration payloads does not allow peers to
>  "hijack" addresses from other nodes.

That's definitely a start. But it doesn't cover the time shifting aspect 
which MOBIKE introduces.

With just IKEv2 the SG can derive some security from the fact that the 
host is still reachable at the same address it used when it initially 
established the IKE and IPsec SAs.

But MOBIKE allows the host to change that.
As a result, some SG practices which might be safe today or with some 
IKE extensions (e.g., BTNS), might not be as safe when combined with MOBIKE.

And MOBIKE, as applied to VPN cases where the SG has good enough(tm) 
authorization can be safe, but other IKE extensions might make it unsafe.

I think covering this "might not be safely extended" aspect is the 
warning I'd like to see in the security considerations section.

> And in Section 1.2 (Limitations) change:
> 
>   This document focuses on the main scenario outlined above, and
>   supports only tunnel mode IPsec SAs.
> 
> =>
> 
>   This document focuses on the main scenario outlined above, and
>   supports only tunnel mode IPsec SAs when at least one of the
>   parties is a VPN gateway.
> 

That's good. But I think the paragraph below which says

    The base version of the MOBIKE protocol does not cover all potential
    future use scenarios, such as transport mode, application to securing
    SCTP, or optimizations desirable in specific circumstances.  Future
    extensions may be defined later to support additional requirements.
    Please consult the MOBIKE design document [Design] for further
    information and rationale behind these limitations.

is misleading, since it might make folks think it is trivial to extend 
it to transport mode, when in fact any such extensions need to carefully 
look at address ownership issues. (And I can't see a tractable solution 
other than HBA or CGA for this.)

So I'd suggest replacing it with

    The MOBIKE protocol as specified handles the case where at least one
    end is a VPN gateway that employs proper authorization of the inner
    tunnel address. As such it can avoid the address ownership issues.
    Extending MOBIKE or applying it other cases (end-to-end tunnel mode,
    transport mode, BTNS) would need to carefully look at the address
    ownership issue and any resulting time-shifting attacks.
    Please consult the MOBIKE design document [Design] for further
    information and rationale behind these limitations.

   Erik