< draft-radha-msec-ckmd-00.txt		draft-radha-msec-ckmd-01.txt >
	Internet Engineering Task Force Radhakrishna Sampigethaya		Internet Engineering Task Force Radhakrishna Sampigethaya
	INTERNET-DRAFT Mingyan Li		INTERNET-DRAFT Mingyan Li
	Radha Poovendran		Radha Poovendran
	Dept. of Electrical Engineering		Dept. of Electrical Engineering
	University of Washington, Seattle		University of Washington, Seattle
	C. Berenstein		C. Berenstein
	University of Maryland, College Park		University of Maryland, College Park
	October, 2001		April, 2002
	Centralized Key Management and Distribution for Dynamic		Centralized Key Management and Distribution for Dynamic
	Multicast Groups: Scalabilility Issues		Multicast Groups: Scalability Issues
	<draft-radha-msec-ckmd-00.txt>		<draft-radha-msec-ckmd-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working		groups. Note that other groups may also distribute working
	documents as Internet Drafts.		documents as Internet Drafts.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	six months and may be updated, replaced, or obsoleted by other		six months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as		Drafts as reference material or to cite them other than as
	"work in progress."		"work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed		The list of Internet-Draft Shadow Directories can be accessed
	at http://www.ietf.org/shadow.html.		at http://www.ietf.org/shadow.html.
	This document expires on April, 2002		This document expires on October, 2002
	Abstract:		Abstract:
	=========		=========
	We present our work on efficient scalable solutions to the hierarchical		We present our work on efficient scalable solutions to the hierarchical
	key management and distribution problem for secure multicast sessions.		key management and distribution problem for secure multicast sessions.
	We take two rooted-tree based schemes that solve hierarchical key		We take two rooted-tree based schemes that solve hierarchical key
	management and distribution problem and then present ways of making		management and distribution problem and then present ways of making
	these schemes more efficient by reducing the tree center key storage		these schemes more efficient by reducing the tree center key storage
	with an upper bound on key update communication. The objective of		with an upper bound on key update communication. The objective of
	skipping to change at page 14, line 35 ¶		skipping to change at page 14, line 35 ¶
	of the log_a(N) tree levels.		of the log_a(N) tree levels.
	The GC storage would be O(N) as the number of leaf nodes will be fixed		The GC storage would be O(N) as the number of leaf nodes will be fixed
	by the group size N. The user storage, though numerically slightly less		by the group size N. The user storage, though numerically slightly less
	than OFT, will still be O(log N).		than OFT, will still be O(log N).
	2.2.4 Comparison between LKH, OFT, OFC:		2.2.4 Comparison between LKH, OFT, OFC:
	---------------------------------------		---------------------------------------
	Comparison between LKH and OFT:		Comparison between LKH and OFT:
	Both the LKH, OFT and OFC have a tree structure, and the height of the		Both the LKH, OFT and OFC have a tree structure, and the height of the
	tree determines the user storage and the key update communication as		tree determines the user st has been rigorously
	O(log_a(N)) for all the schemes. The GC storage for the three schemes
	is related to the group size N as O(N). However, the schemes are
	different in the way the keys are computed and stored. The keys on a
	LKH tree are generated independently, and the GC has to store all the
	keys of a tree. Hence, the GC storage of the LKH depends on the tree
	height, which is a function of the tree degree a and the group size N.
	In contrast, in OFT and OFC, given all the leaf keys at the bottom
	level of the tree, the GC can derive all other keys on the tree.
	Therefore, the GC in OFT and OFC only stores all the leaf keys and the
	GC storage is independent of the degree of the tree. Note that LKH has
	the GC storage as (aN-1)/(a-1), which is a function of the degree of
	the tree.Between OFT and OFC, the difference is in the function that
	is used tocompute the upper level keys from the lower level keys.
	Also, thesecurity of the OFC scheme, unlike OFT, has been rigorously
	proved because of the solidarity of pseudo-random function used in		proved because of the solidarity of pseudo-random function used in
	OFC. In [Can 2] the authors have claimed the security of OFC to be		OFC. In [Can 2] the authors have claimed the security of OFC to be
	better than that of LKH. More specifically, if assuming that a third		better than that of LKH. More specifically, if assuming that a third
	party, which is capable of decrypting encryptions in a certain subpace		party, which is capable of decrypting encryptions in a certain subpace
	(referred to as 'weak subspace'), takes control of the GC, then the		(referred to as 'weak subspace'), takes control of the GC, then the
	third party could generate keys on the LKH tree such that they appear		third party could generate keys on the LKH tree such that they appear
	to be random, but the encryptions that use these keys would always be		to be random, but the encryptions that use these keys would always be
	in the weak subpace. Hence a third party could hack into the		in the weak subpace. Hence a third party could hack into the
	communications of a multicast group which uses the LKH scheme.		communications of a multicast group which uses the LKH scheme.
	However, in the OFC scheme, the root key as well all other keys on the		However, in the OFC scheme, the root key as well all other keys on the
	skipping to change at page 31, line 49 ¶		skipping to change at page 31, line 49 ¶
	Tel: +1 301 405-6845		Tel: +1 301 405-6845
	11. Acknowledgments:		11. Acknowledgments:
	====================		====================
	We would like to thank Dr. Eric J. Harder at National Security Agency		We would like to thank Dr. Eric J. Harder at National Security Agency
	(NSA) and David A. McGrew at Cisco Systems, for their useful comments.		(NSA) and David A. McGrew at Cisco Systems, for their useful comments.
	Our work has been supported by the National Science Foundation under		Our work has been supported by the National Science Foundation under
	NSF Faculty Career Development Award ANI 00-93187.		NSF Faculty Career Development Award ANI 00-93187.
	This document expires on April, 2002		This document expires on October, 2002
End of changes. 6 change blocks.
	19 lines changed or deleted		5 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/