Subject: [Mobike] issue 27 -- security for path testing

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Aug 2005 14:14:29 +0300

This issue relates to the lack of security considerations
text on path testing. In Paris we decided, obviously
enough, that more text would be needed and that
the actual text would depend on the resolution to issue
34, how path testing is actually done.

In an effort to speed the process up a bit, I wrote
the below text suggestions that correspond to the
different outcomes of issue 34.

The first text suggestion (A) is what we would use if
we continue to use the path testing scheme in -01.
That is, the path test messages are unprotected.

The next text suggestion (B) is what we would use if
we adopt Tero's path testing scheme where the
test messages are regular IKEv2 Informational
exchanges.

Finally, there are some common text changes (C) that
are needed in any case.

Please comment.

--Jari

Change A
======

Add a new paragraph at the end of Section 4:

  MOBIKE also employs its own path test messages
  and can only provide limited protection for them. Specifically,
  these messages are sent outside the protection of the IKE
  SA and can therefore be spoofed, modified, or read. However,
  MOBIKE initiators do not use these messages beyond confirming
  that a sent message gets a response and finding out the
  characteristics of the path (addresses and NATs).  MOBIKE
  responders do not use these messages at all, beyond
  blindly responding to them.

  A cookie mechanism ensures that attackers cannot send a response
  blindly without seeing a request first. Nevertheless, on-path
  attackers can intercept legitimate requests and responses,
  and either prevent them from reaching the destination,
  carrying them to the destination even across networks that
  would not let other packets through, or modify NAT behaviour
  enroute. As a result, these attacks may lead to denial-of-service.
  Note that denial-of-service is typically possible for on-path
  attackers even without the MOBIKE messages, e.g., by blocking
  IKE messages.

Change B
======

Add a new paragraph at the end of Section 4:

  MOBIKE also employs its own path test messages
  and can only provide limited protection for them. Specifically,
  while these messages are protected by the IKE SA, the
  relevant information in these messages is mainly in the
  unprotected parts such as the IP header, and can therefore
  be spoofed, modified, or read. MOBIKE initiators do not
  use these messages beyond confirming
  that a sent message gets a response and finding out the
  characteristics of the path (addresses and NATs).  MOBIKE
  responders do not use these messages at all, beyond
  blindly responding to them.

  A cookie mechanism ensures that attackers cannot send a response
  blindly without seeing a request first. Nevertheless, on-path
  attackers can intercept legitimate requests and responses,
  and either prevent them from reaching the destination,
  carrying them to the destination even across networks that
  would not let other packets through, or modify NAT behaviour
  enroute. As a result, these attacks may lead to denial-of-service.
  Note that denial-of-service is typically possible for on-path
  attackers even without the MOBIKE messages, e.g., by blocking
  IKE messages.

Common Changes C
=============

In Section 4 we have the following text:

   Spoofing indications related to network connectivity

         Attackers may also spoof various indications from lower layers
         and the network in an effort to confuse the peers about which
         addresses are or are not working.  For example, attackers may
         spoof ICMP error messages in an effort to cause the parties to
         move their traffic elsewhere or even to disconnect.  Attackers
         may also spoof information related to network attachments,
         router discovery, and address assignments in an effort to make
         the parties believe they have Internet connectivity when in
         reality they do not.

         This may cause use of non-preferred addresses or even denial-
         of-service.

Add the following to the end of the second paragraph:

        Finally, attackers may spoof information related to the path
        test messages employed by MOBIKE itself.

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Aug 2005 13:19:23 +0300

>   attackers even without the MOBIKE messages, e.g., by blocking

I do not know if the is belongs to here, but the those path test
messages might also be filtered out by statefull content inspection
devices (firewalls, intrusion detection / prevention systems etc), as
they are not part of any existing IKE SA, and some devices might
consider source IKE SPI being 0 as an attack.

I do know that old NAT boxes used to do IKE SA session tracking based
on the IKE SPIs and they did the demultiplexing of the incoming
packets based on the IKE SPIs instead of ports. This shouldn't be
problem here as we are using port 4500 instead of port 500, and NATs
should not do that on port 4500.

I am just wondering if there is any boxes that filter IKE packets in
that kind of statefull way.

The paragraph above also requires some text about replay attacks, i.e.
stating that each cookie used MUST be unique, and each cookie has only
certain time window and after that it is forgotten, and if packet
having that cookie is later received it must not be accepted. If we
use the path testing inside IKE, then there is message id's taking
care of the replays, thus cookies does not need to be unique, they
simply need to be non-guessable. 

Also in general each cookie is tied to the specific address pair it
was sent to. I.e. if same cookie is used for multiple addresses pairs,
then malious host B can fake an response back from the address where
it actually didn't see the message. This is mostly for B as there we
do need to retransmit the packet to other addresses if we do not get
reply back (and in which case we should restart path testing), but
also for C as this must be taken care of in both cases. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 15:53:28 +0300

>consider source IKE SPI being 0 as an attack.
This is certainly something that we should document.
Thanks for bringing it up!

>simply need to be non-guessable. 
Yes. Uniqueness is handled in Section 3.5 already, I think.
For the rest we need new text.

>also for C as this must be taken care of in both cases. 
Right. Thanks. Here's an updated text:

Change A
======

  Given that the path test messages use cookie values of zero
  for both ends, its possible that firewalls that inspect
  IKE packets may filter out packets with the sender's SPI
  set to zero.

  Sections 2.5 and 3.5 provide a mechanism which ensures that
  old path test messages can not be replayed, and that responses
  can not be blindly switched to appear to come from a different
  address.

Add to 2.5 COOKIE2 notification payload:

   The use of COOKIE2 is necessary to ensure that the peer cannot
   generate the correct response without seeing the request. The
   sender of the PATH_TEST exchange MUST include a COOKIE2 notification
   payload. The data in this payload MUST be randomly chosen
   as described in Section 3.5, for each new packet that is
   sent.

   The recipient MUST copy the payload as-is to the response.
   When processing the response, the original sender MUST verify that
   the value is the same one as sent, within a reasonable time window
   to avoid replaying old values.  If the values do not match, the
   response MUST be silently ignored.