[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: overcomplicated framework for multicast security without real value


Justin,

Your note seems more suitable for the SMuG (Secure Multicast Group) working
group of the IRTF, where multicast key management is discussed among
other multicast security issues. The draft you read is one of the early 
drafts written by SMuG contributors; other work has been done since. 

The list is a "closed" one; but anyone who wants to contribute is most
welcome to join. To do that, please write either myself or Thomas
Hardjono (hardjono@nortelnetworks.com).

Regarding your note, I agree with much of what you say. Indeed, there is
a need to find a good compromise between simplicity and immediate
applicability and some generality that would allow future extensions
without re-doing everything from scratch.  But I wanted to
point out one thing that you seem to have missed in that draft (at least
according to my understanding of it): the separation to "trunk region key" 
and other keys is relevant only to the re-keying messages. All the data
is encrypted using one key that is common to all members. Thus,
end-to-end security of the data is maintained. (In some cases,
such as political barriers and some firewalls, one may be forced to 
re-encrypt the data. But this should be avoided whenever possible.)


Best,

Ran Canetti


> 
> From owner-ipsec@lists.tislabs.com Mon Jun 19 17:37:31 2000
> Date: Mon, 19 Jun 2000 14:10:27 -0700 (PDT)
> From: Justin Young <justin_young_98052@yahoo.com>
> Subject: overcomplicated framework for multicast security without real
> valueTo: ipsec@lists.tislabs.com
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Precedence: bulk
> Content-Length: 4395
> 
> My company is working on a project for Internet
> streaming applications. I just finished reading "A
> Framework for Group Key Management for Multicast
> Security" and like to share some thoughts.
> 
> Although authors are aware of the challenges of
> multicast security and understand the requirements
> imposed by different multicast applications, this
> framework is nearly useless in the real world.
> 
> It's too complicated to implement and deploy, and
> provides little value in return for most applications.
> While ISPs may celebrate the opportunity for
> increasing the number on subscribers' monthly bill,
> the introduction of "trunk region" complicates the
> overall multicast security infrastructure and makes
> secured data distribution more vulnerable since it
> breaks the end-to-end security model. Some people may
> not want any third-party (ISP) get involved in the
> sensitive data transmission. And for most applications
> (as I will discuss below), this approach doesn't
> improve the scalability or performance after all.
> 
> Authors claim that the primary advantages of the
> framework are (1) more scalable (2) reduced
> complexity, and illustrate them on two examples:
> Pay-per-view and Confidential Conferencing. Now let's
> look at them one by one.
> 
> Case 1 - Pay-per-view (one-to-many): as the name says,
> you have
> to pay for per movie/live sport event/TV show and it's
> not refundable once you make the payment (even you
> change your mind after only ten minutes because the
> movie sucks). After each show, you have to pay again
> to register for another one. That means the lifetime
> of membership is fixed. All the members have to renew
> their session key for the complete next lifetime. In
> another word, the application server or key
> distribution server only has to maintain single
> session key for everybody within a single life time
> (bounded by show time) even some viewers may switch
> channel or leave their computer. This type of service
> is the majority of future multicast applications. The
> nature of those applications is that all members have
> to renew their group keys for each event. In this
> case, the proposed framework doesn't provide any value
> if not making it worse.
> 
> You may argue that different members may have
> different lifetime, for example some couch potato may
> register a whole year for every pay-per-view events
> (if permitted by the ASP). But in this case, it makes
> better sense for ASPs to create several different
> membership levels and separate the management for each
> level (within application-specific context).
> 
> In the near future, most streaming ASPs will most
> likely offer two types of multicast streaming
> services: monthly viewing service and pay-per-view.
> Time Warner has been doing it for years in its cable
> network. It seems this framework can be used to
> manage monthly viewing service. Members may call up
> and open/close their accounts anytime during the
> month.
> But is it really worth going through all that trouble
> while you can simply renew the key for everybody once
> every day (you have to renew it sooner or later anyway
> for security reason)? The point is that the timing
> granularity requirement is loose.
> 
> Case 2 - Confidential Conferencing (many-to-many): the
> framework fits better for this type of
> application. But the nature of conference is that only
> limited number of people will attend. So you don't
> need scalability. You may ask: ever attend a meeting
> with over hundred people? That will be a party, not a
> conference. In a party, people usually gather into
> smaller groups and talk about their friends' private
> lives. In this case, people don't want their
> conversation to be heard by everybody and it's
> unnecessary for doing so. And still, even hundred
> members can be managed without any hierarchy. If the
> number increases, the group/conference usually will
> be divided into smaller groups each with different
> focus (like how IETF divides its working groups). In
> most cases the only event everybody participates may
> be listening to the speech of a single member, this
> becomes the one-to-many scenario.
> 
> The bottom line is that unless authors can identify
> the services or applications (something requires
> extreme quick response for membership change) where
> this framework can really make sense, in my opinion,
> every day (you have to renew it sooner or later anyway
> for security reason)? The point is that the timing
> granularity requirement is loose.
> 
> Case 2 - Confidential Conferencing (many-to-many): the
> framework fits better for this type of
> application. But the nature of conference is that only
> limited number of people will attend. So you don't
> need scalability. You may ask: ever attend a meeting
> with over hundred people? That will be a party, not a
> conference. In a party, people usually gather into
> smaller groups and talk about their friends' private
> lives. In this case, people don't want their
> conversation to be heard by everybody and it's
> unnecessary for doing so. And still, even hundred
> members can be managed without any hierarchy. If the
> number increases, the group/conference usually will
> be divided into smaller groups each with different
> focus (like how IETF divides its working groups). In
> most cases the only event everybody participates may
> be listening to the speech of a single member, this
> becomes the one-to-many scenario.
> 
> The bottom line is that unless authors can identify
> the services or applications (something requires
> extreme quick response for membership change) where
> this framework can really make sense, in my opinion,
> we'd better be thinking something else.
> 
>