Subject: Re: Scalability of key management -- Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt

From: Ran Canetti <[email-masked]>
Date: Fri, 29 Jun 2001 11:23:40 -0400

Regarding the scalability issue, and whether there should be centralized
or distributed key servers, and whether the key servers should double up 
as group members:

The current GKM architecture defines registration and rekey protocols 
(and possibly deregistration in the future). How does the question of 
centralized/distributed design affect these protocols, if at all?  

My impression is that the registration/rekey/deregistration protocols
are to a large extent agnostic to whether there is a distributed or 
centralized design. And this is very good news: it means that msec does 
not need to decide between centralized/distributed designs - our protocols 
can live with either design, and we can leave it to the  future system 
architects to decide how to organize their application.

Ran

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

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 09:35:43 -0700

Ran

>architects to decide how to organize their application.

I agree.  It's an architecture question, however, whether the protocols
are sufficient to allow large-scale operation for source-specific multicast:
Do we need to have a inter-GCKS protocol, for example?  So while what
you say is true, the question remains as to whether we are missing
something.  I don't think we are, but the gkm architecture needs to
consider this.

I am fine with removing the centralized versus distributed key management
issues from the I-D since this leads to long discussions and lots of
disagreement on what centralized means and what distributed means.

Mark