Subject: [MSEC] rekeying completed ?

From: Lee Fu-yuan <[email-masked]>
Date: Sat, 11 Aug 2001 00:13:08 +0800

hi all:

	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 ?

	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. 
	
	Moreover, are there any papers or technical reports discussing 
	about packet loss pattern in MBone, i.e. the loss rate of MBone.

	Thanks a lot. :)

-- 
Lee, Fu-Yuan
Distributed System and Network Security Lab.
Dept. of Comp. Sci. & Info. Eng
Nat'l Chiao Tung Univ.
Hsinchu, Taiwan 30050, ROC 
E-Mail: [email-masked]

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

---

From: Mark Baugher <[email-masked]>
Date: Fri, 10 Aug 2001 13:18:40 -0700

>hi all:

Hello to you

>         the group member may use old group key. On the contrary, if the

We will have the IETF-51 presentation by Lakshminath posted on a web
site very soon that addresses this topic.

>         overhead and the trust relationship of internal nodes such Mrouters.

I contribute my $0.02 to this soon.  I just got back from London and
practicing triage on my inbox.

Cheers, Mark

---

From: Hugh Harney <[email-masked]>
Date: Mon, 20 Aug 2001 09:36:19 -0400

Lee,

In discussing the unreliability of the LKH, OFT, OFC rekey action the 
security relevance is highly dependant on the application. If one is 
looking at a single source broadcast then the impact of a member not 
receiving a rekey is the loss of access to the data. This is obviously bad. 
However, in the case of multiple sources of data the impact of a member not 
receiving a rekey is possible loss of confidentiality, and loss of access. 
I'm ignoring the issue of source authentication because it is dependant on 
the source authentication protocol used.

In the case of a single source broadcast (with the data source closely 
linked with the rekey authority) the failure of group members to receive 
the key to decrypt the data is a denial of service problem. There are 
several potential mechanisms to help this situation: more reliable 
multicast transmission protocols, member initiated rejoins, and application 
layer actions to improve reliability of the rekey message (multiple sends).

The case of multiple sources of data on a group is more problematic. If an 
adversary managed to isolate a subset of the group and cut that subset off 
from the group rekeys, the isolated subset would continue to use the old 
group key. If that old group key were inappropriately disclosed 
(compromised) the data sources in the isolated subgroup would be disclosing 
information (encrypting data on a "bad" key).

There are a couple of ways to help mitigate this problem in the LKH 
architecture. First, the cryptographic keys could be given a life span to 
limit the window of opportunity for transmission on a bad key. Second, a 
periodic rekey could be sent out, as an expected event, to the group. If a 
group member does not receive the rekey, that would signal two things - 
loss of common group key and a potential active attack. The group member 
that is encrypting data for the group would have to assume that the "old" 
group key is outdated and stop transmitting on that key. The members would 
then have to either notify the GC of the loss of cryptographic synch or 
rejoin the group. Both of these approaches limit the window of 
vulnerability to an isolation attack, but do not prevent the attack.

It seems to me that there is a tradeoff between architecture complexity and 
risk when discussing LKH vs. Iolus. This tradeoff would be highly 
application dependant.

Hugh

>         about packet loss pattern in MBone, i.e. the loss rate of MBone.

________________________________________________________
Hugh Harney		[email-masked]		410-381-9400 x203
________________________________________________________