Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode?

From: Jari Arkko <[email-masked]>
Date: Wed, 01 Feb 2006 17:02:09 +0200

I do not have a strong opinion on where text should
go. But personally I would like to see some note
about the inner address allocation authorization issues
(even if that note pushes the blame to IKEv2 where it
belongs).

--Jari

[email-masked] wrote:

>Hmm.. I think this is more a limitation of MOBIKE (and IKEv2
>in general) rather than a security consideration of MOBIKE.
>
>How about adding this to Section 1.2 (Scope and Limitations)?
>
>   IKEv2 relies on information in the Peer Authorization Database
>   (PAD) when determining if the peer is authorized to create an IPsec
>   SA with particular traffic selectors. MOBIKE does not change this
>   part of IKEv2. This may limit the applicability of MOBIKE in
>   host-to-host IPsec scenarios: although MOBIKE allows the peers to
>   update the tunnel header addresses, it does not modify the child SA
>   authorization data in the PAD. In other words, using some particular
>   tunnel header address does not imply that the peer is authorized
>   to create IPsec SAs with that address in the traffic selector.
>
>Best regards,
>Pasi
>
>  
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of ext Jari Arkko
>>Sent: 31 January, 2006 14:42
>>To: Erik Nordmark
>>Cc: MOBIKE Mailing List
>>Subject: Re: [Mobike] does mobike support end-to-end use of 
>>tunnel mode?
>>
>>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:
>>
>>  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.
>>
>>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.
>>
>>--Jari
>>    
>>
>_______________________________________________
>Mobike mailing list
>[email-masked]
>https://www.machshav.com/mailman/listinfo.cgi/mobike
>
>
>  
>

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 11:51:05 -0800

> a new subsection to be added to the security considerations

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

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

>   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