Subject: [Ipsec] comment on "empty message" in IKEv2 draft

From: "Yonghui Cheng" <[email-masked]>
Date: Thu, 12 Aug 2004 14:34:46 -0700

All,

The IKEv2 draft/RFC should emphasis that when send "empty" messages

in IKEv2, the actual messages should include an empty "encrypted
payload".

"Empty" messages is used for DPD (dead peer detection) and acknowledge

purposes. Without encrypted payload, the message is not authenticated,

which should considered as security problem.

Yonghui

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Aug 2004 13:08:17 +0300

> in IKEv2, the actual messages should include an empty "encrypted

True. 

> which should considered as security problem.

Note, that empty messages can be used for dead peer detection, but
they cannot be used to proof liveness. I.e the malicious peer can
create responses to empty DPD messages before hand and give them
forward to somebody using them to claim the other end that he is not
dead even when he might have already been gone.

This makes for example DPD done after the NAT-T not so secure as it
could be. I.e. malicious initiator can use NAT-T to do 3rd party
bombing against 3rd party, and continue doing that even when the
server tries to do return routability checks.

There would be easy fix for that, simply server includes the N(COOKIE)
notify payload inside encrypted payload in the DPD, and then we simply
add text to the draft-ietf-ipsec-ike2 draft saying inside the "COOKIE
16390" section saying:

	If this notification mesasge is received in any request, it
	MUST be included in the reply packet, with the exactly same
	data.

This would allow the servers to decide which kind of return
routability checks (if any) they will do with NAT-T. 
-- 
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Aug 2004 13:32:50 +0200

In your previous mail you wrote:

   
=> A nonce payload should have the same result, quoting the IKEv2 draft:

   The Nonce Payload ... contains random data used to guarantee liveness
   during an exchange and protect against replay attacks.

   I don't know what is better, COOKIE notifications or nonces. The only
   visible difference is the length (1-64 for cookies, 16-256 for nonces)
   but this is not enough to choose. Same about the stateless property
   of cookies, here we have an IKE SA so already some state...
   What do readers of this mailing-list prefer? In any case we'll get
   this mechanism in MOBIKE.

Regards

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Aug 2004 11:32:31 +0300

> => A nonce payload should have the same result, quoting the IKEv2 draft:

Nope. 

>    during an exchange and protect against replay attacks.

Nonce are always generated by the sender, and it is random nonce,
which is used during the auth process. It is not replied back in any
of the exchages, so it would not really guarantee liveness in this
case. 

>    this mechanism in MOBIKE.

COOKIE is the only option, nonce is not an option, as it is not sent back.
-- 
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Aug 2004 11:35:28 +0200

Nope. 

   
=> the text is from the IKEv2 draft 14... And we can do what we want
with nonces, as we can do what we want with COOKIE notifications,
like adding the text you proposed.

=> I don't buy this argument: I prefer Yonghui's one, i.e., cookie has
already this connotation (a weak form of the "least astonishment" argument).

Thanks