Subject: [Mobike] Issue 27: Security and path testing (was: Comments on draft-ietf-mobike-protocol-00.txt)

From: <[email-masked]>
Date: Tue, 12 Jul 2005 14:44:43 +0300

Mohan Parthasarathy wrote:
> -Path testing: 
>- The security impact of this is not discussed in the 
> Security consideration section ?

True, something needs to be added.

> - It states that the reason for new message type is to support
> window size 1.  But it does not state why it can't be secure ? 
> You can still have a separate window space for this message and 
> still provide security, right ? This was discussed in the mailing 
> list. Do you see problems with it ?

It certainly would be possible to encrypt and integrity protect
the path test messages, but I'm not sure if this would actually
improve the security at all.

- An attacker can see the contents of the messages, but since
  they don't actually contain anything interesting, encryption
  does not help here (e.g. NAT detection payloads are sent in 
  clear even in normal IKEv2).

- An attacker could drop the messages and cause the initiator 
  to believe the path does not work (well, that would be a 
  reasonably correct belief in this case). Clearly integrity
  protection does not help here.

- An attacker could modify the contents of the messages. 

  Modifying the COOKIE2 payload has the same effect as dropping 
  the message (initiator thinks the path does not work, reasonably
  correctly so), so no benefit from integrity protection here
  either.

  Modifying the NAT detection payloads seems to have roughly the
  same effect as modifying the IP header or UDP ports, causing
  the parties to detect a NAT where one doesn't exist.

- An attacker can "manufacture" a path test request: not a 
  problem, since this achieves nothing.

- An attacker can "manufacture" a path test response (if it sees
  the corresponding request): I don't think this is a problem
  either. If the attacker has a working path to the responder, it
  could just forward the packet, and let the response come back
  without manufacturing anything.  And the path test message is
  not used as a substitute for dead peer detection anyway, so if
  the peer is really dead, an attacker can't hide that.

And encrypting and integrity protecting these messages is not as
easy as it sounds. For instance, if the response message is
lost, and the initiator retransmits the same request, does the
new response have to be identical to the previous one?  (For
normal IKEv2 messages, the answer is yes. But this implies
keeping state in the responder, with window mechanism to limit
the amount of state that needs to be kept. If the answer would
be yes for path test messages as well, how many path test
messages would have to be kept?)

But perhaps there's some angle I haven't thought about yet;
more comments are welcome...

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Jul 2005 17:50:59 +0300

>   correctly so), so no benefit from integrity protection here

Nope. The section 2.6 says that if N(COOKIE2) values do not match the
IKE_SA MUST be closed... so modifying the path test message COOKIE2,
allows easy DoS attack with single modified packet to close the whole
connection, and as the path test message only has constant data
otherwise, it will cause attacker to be able to create those packets
by just knowing IP and port numbers of the connection...

Or is the COOKIE2 processing different in the informational exchange
and in the path test exchange? If so that is not mentioned in the
draft anywhere. 

> easy as it sounds. For instance, if the response message is

It is actually quite easy, we simply do not use separate exchange for
those...

Not using separate exchange (i.e. getting rid of PATH_TEST exchange)
means that we simply need to define the proper retransmission policy
for IKE packets (which we need to do anyways, and which is missing
from the document), and we need to say that NO changes to the
IKE_SA IP-addresses are done ever unless the there explicit request by
CHANGE_PATH nofity from the other end.

(I will write more about that along with my comments of the draft). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 12 Jul 2005 20:18:39 -0700

mohanp> This is the one i  was mainly concerned with. DPD is
mohanp> done only for the already working path. If we need
mohanp> to know whether an alternate path (.e.g cheaper path)
mohanp> works or not, we need to send PATH_TEST message
mohanp> If you get a false response e.g. when it
mohanp> is not working, attacker sending a response back can cause
mohanp> a failover unncessarily. Yes, DPD now can now
mohanp> detect this and fail back to the other path. But the
mohanp> other path (which was working and still working) can be 
mohanp> "failed" by the attacker by sending a false response.
mohanp> I think this is undesirable. So, i see the PATH_TEST message
mohanp> as DPD but sent with different address pair. 

mohanp> Why do we need to keep state on the responder for
mohanp> sending back same response to a PATH_TEST message?  
mohanp>  The response is an empty message back to the addresses
mohanp> where it came from. NAT-detection is also stateless.
mohanp> So, i am missing something here..

-mohan

Best regards,
Pasi