Subject: Re: [MSEC] rekeying completed ?

From: Ran Canetti <[email-masked]>
Date: Sat, 11 Aug 2001 08:55:17 -0400

Fu-yuan,

> From: Lee Fu-yuan <[email-masked]>
>
>       About group rekeying, I have not seen any proposed schemes
>       mentioned about "rekeying complete message" or something
>       like this. But I am so wondering if we can not make sure
>       that all the group members have already rekeyed successfully, how
>       can these protocols guarantee message confidentiality in case that
>       the group member may use old group key. On the contrary, if the
>       communication must be suspended when the rekeying process is in
>       progress, any adversary can stop the communication by isolating
>       certain member(s).(the member can not complete the rekeying
>       operation) How do you think about this problem ?

Some of the ways that have been suggested to deal with the problem of 
reliability of  transport of the rekeying messages are:
-use standard reliability mechanisms for the reky messages
-use some simple "homegrown" reliability mechanisms, such as repeating the
rekey messages several times, or some other simple fec mechanisms.
-rekey members a bit in advance. that is, start using the new
group key only a little while after rekeying the group. this allows for
people who didnt get the rekeying messages to get it in a later message.
-piggyback the rekey information on the data messages. 
-use a "stateless" rekeying algorithm. here a member that got out-of-synch
can get back in synch by receiving any future rekey message. it does not
need to get the entire chain of rekey messages that it may have missed.

>
>
>       IMHO, the Iolus schems provides better scalability than LKH style
>         protocols since the rekeying operation is confined in local
>         multicast island. But it seems LKH schemes will be adapted into
>       rekeying protocols in this working group. Is there any other
>       disadvantage of Iolus except for its encryption/decrytpion
>       overhead and the trust relationship of internal nodes such Mrouters.

having routers decrypt and re-encrypt each data packet is a serious
drawback,
both from a performance point of view and from a security point of view.
this problem seems to me much more serious than the rekey problem.
one of the basic premises of msec is to try to keep the security independent
from the routing of data packets.

Ran

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

---

From: Mark Baugher <[email-masked]>
Date: Sat, 11 Aug 2001 10:56:31 -0700

>rekey messages several times, or some other simple fec mechanisms.

For many applications, even for video on demand, it is a good solution
to send a stream of keys concurrently with (but encoded independently from)
the data.   That way, someone who starts receiving ("tunes to") a
particular data stream can start deciphering it within a bounded amount of
time.  For video on demand, there may be no such tuning or "channel
surfing," so the key stream may only need to be sent for some period
of time after the commencement of the data stream.  KEK- based
group key management schemes offer a fast way to start up broadcast
or on-demand streams that are encrypted.

Mark