Subject: [MSEC] Comments on MIKEY draft

From: Ran Canetti <[email-masked]>
Date: Thu, 22 Nov 2001 14:54:56 -0500

I read the MIKEY draft (<draft-ietf-msec-mikey-00.txt>)
and thought that it is well-written, a pleasure to read.
It also seems technically and cryptographically sound in general.
(Most glitchs from the previous version were indeed fixed.)
Some remarks, nonetheless:

- My main concern regarding the applicability of MIKEY is still the fact
that it inherently uses timestamps for liveness. Indeed, timestamps are
used in telephony and also on small scale on the internet (kerberos/kink),
but this is the first time that they are suggested for a large scale
protocol, based on PKI, and without prior coordination between the two
endpoints. This brings in the issue of how synchronized the clocks should be
required to be. 

If I understand correctly, the approach taken by MIKEY is to have each 
partner keep a cache of the messages received in the past X time units, 
and discard an incoming message if it is a replay of a message in the cache.
This means that the cache should be large enough to contain all received
messages within the last X time units, where X is at least as large as 
the allowed clock skew. This puts a clear tradeoff between memory/state 
size and the amount of synchronization required. I guess only time and 
experience will tell whether there is a viable solution to this tradeoff 
that can work on a large scale. 

- Section 3.3 (Diffie-Hellman): you dont say what this type of exchange buys
that the previous one does not. The answer seems to be that it buys forward
secrecy. Please discuss.

- You mention the notion of a multimedia crypto session that contains
several "simple" crypto sessions. It may be helpful to use the notion of a
"session bundle" where all sessions in the bundle use the same MIKEY
exchange and the same rekey protocol.

Finally, it should be interesting to see how MIKEY would fit into the GKMARCH
framework - perhaps as another "registration protocol", or perhaps
otherwise.

Best,

Ran

BTW, are you aware of an implementation effort of MIKEY?

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

---

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Tue, 27 Nov 2001 11:01:16 +0100

Ran, 
thank you very much for the comments!
(see my comments below)

> that can work on a large scale. 
Yes, that's what we hope the new draft explains better.
The use of timestamps may of course raise some concern. 
However, we believe that it is possible to use timestamps 
in certain scenarios (as the ones that MIKEY addresses). 

> that the previous one does not. The answer seems to be that 
Sure

> exchange and the same rekey protocol.
Ok

> framework - perhaps as another "registration protocol", or perhaps
Indeed, and I think it will be feasible to fit MIKEY into 
the GKMARCH framework. 

> BTW, are you aware of an implementation effort of MIKEY?

We are of course implementing MIKEY together with SRTP in a 
SIP client. For the moment, I am not aware of any other 
implementation effort. 

Thanks, 
Fredrik