Subject: [MSEC] A couple remarks on MIKEY

From: Ran Canetti <[email-masked]>
Date: Thu, 27 Jun 2002 22:40:31 -0400

Hello MIKEYers - 

For the sake of lazy readers like me, could you highlight the points 
in which the new MIKEY draft differs from the pervious ones? 

Also, two questions/remarks, both regarding the issue of timestamps:

-You say in section 5.4 that implementations may dynamically 
increase/decrease the "degree of looseness" (or, the time interval
from which timestamps are accepted). Can you elaborate on how this is done? 
In particular, is this a purely local decision to a party or does it require 
some negotiation or notification to the other party? (The answer should 
probably be mentioned in the i-d.)

-Section 9.5 (denial of service in the security considerations section),
should probably discuss the potential DoS hazards that stem from the 
timestamp and message-buffering mechanism. how bad is it, and how to 
mitigate it?

Thanks,

Ran

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: "Fredrik Lindholm (EAB)" <[email-masked]>
Date: Fri, 28 Jun 2002 13:19:20 +0200

Hi Ran,

From a technical point of view, not much have been changed in the draft. 
However, we restructured it and added more explanations to address the 
comments received by Mark and Martin. The main changes from -01 draft are:
* Removed: Support for Re-key SA including KEK transport for all methods.
* Timestamp required explicitly in the verification message
* Renamed R flag in Common header to V (for verification)
* Change of notation  
  - Pre-Master Key (PMK) --> TEK Generation Key (TGK)
  - Multimedia Crypto Session (MCS) --> Crypto Session Bundle (CSB)
  - Some payloads have also had their name changed.
  - Seed (in the PRF definition) --> Label
* General extensions payload added.
* Possibility to send a TEK only (instead of a TGK) is provided for
  pre-encryption purposes.
* General updates of all sections (trying to address all comments
  received from the list).   
* IANA considerations added

(see also comments inline)

<snip>
> probably be mentioned in the i-d.)

I'll give you the very short version here (and I will try to 
extend it in the draft). It is a local decision.

> timestamp and message-buffering mechanism. how bad is it, and how to 

Ok, I will extend the discussion of this. 

Cheers,
Fredrik

---

From: Ran Canetti <[email-masked]>
Date: Fri, 28 Jun 2002 08:57:04 -0400

Thanks!
looks good.

Ran