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

From: "Yonghui Cheng" <[email-masked]>
Date: Fri, 13 Aug 2004 11:10:03 -0700

Cookie is better (closer to ike convention).

The convention is, cookie is something need to be returned by peer,
yet exchange of nonce payloads can proof the freshness of both sides. 
Besides, nonce is never returned by peer (in IKE).

Yonghui

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, August 13, 2004 4:33 AM
To: Tero Kivinen
Cc: Yonghui Cheng; [email-masked]
Subject: Re: [Ipsec] comment on "empty message" in IKEv2 draft 

 In your previous mail you wrote:

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

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

---

From: "Charlie Kaufman" <[email-masked]>
Date: Mon, 16 Aug 2004 18:46:04 -0700

While I believe the IKEv2 spec is unambiguous when read carefully, I
agree that it would be clearer if it explicitly said that an "empty"
message actually consists of an empty "encrypted payload".

I don't think this warrants a new draft, but if something else requires
a new draft (or if I'm allowed to make such minor changes during
author's 48 hour call), I will fix it.

	--Charlie

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yonghui Cheng
Sent: Thursday, August 12, 2004 2:35 PM
To: [email-masked]
Subject: [Ipsec] comment on "empty message" in IKEv2 draft

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

---

From: [email-masked]
Date: Tue, 17 Aug 2004 12:07:39 +0300

Charlie Kaufman wrote:
>
> I consider it too late to get this into the IKEv2 spec. I hope I'm not
> wrong about that. If so, we should think of this as the first of many
> extensions to IKEv2. IKEv2 was designed for extensibility. If we can't
> make this one, we clearly blew it.

Yes, I agree it's too late, and this can be done as an extension
(possibly at MOBIKE) later.

Regards,
Pasi