--------------------

Mohan Parthasarathy (2005-07-11):

-Path testing: 
- The security impact of this is not discussed in the Security consideration
  section ?
- 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 ?

--------------------

Pasi Eronen (2005-07-12):

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

--------------------

Tero Kivinen (2005-07-12):

>    MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing
>    connectivity.  This exchange is not part of any IKE_SA, so it is not
>    cryptographically protected.  It also does not result in the
>    responder keeping any state.

I do not like this non-protected exchange, as its security
implications are not known. For example the text below, does not say
what to do if the N(COOKIE2) are not matching. The other place said we
tear down IKE SA, but we do not want to do it here. 

<snip>

> 4.  Security considerations
...
>    Protection of MOBIKE payloads
> 
>       The payloads used in MOBIKE are encrypted, integrity protected,
>       and replay protected.  This assures that no one except the
>       participants can, for instance, give a control message to change
>       the addresses.

This is not true, as PATH_TEST packets in the current document are not
encrypted or proteced. This should be mentioned here, and security
analysis of all possible attacks this new protocol might cause should
be done.

--------------------