Subject: Re: [MSEC] Re: applications and motivation for mcast and groupsecurity

From: "Girish Chandran" <[email-masked]>
Date: Thu, 17 Mar 2005 15:50:08 -0600

Roger,

As Mark mentions below satellite applications are ideally suited for
multicast.
Satellite broadcasts of say soccer matches (pick your favorite event)
are often protected 
by conditional access keys for individual TV stations / subscribers.
For example coverage of
Major League Baseball by say Fox ....all Fox TV affiliates in the US
could be part of a multicast group.
Radio affiliates could be part of another group...etc. A multicast
group security model is ideal here. 
Distance Learning...say over satellite is another app.

Transport for these is typically not IP...however there is a lot of
activity to move a lot of these types of apps to IP. 

Girish

>>> Mark Baugher <[email-masked]> 3/17/2005 4:27:09 PM >>>
Roger
   There is some work that is product-related that won't be discussed
on  
this list before the products are announced.  There are some  
opportunities in group and multicast applications, but IP multicast is 

not widely deployed and has been much slower in its adoption than some 

of us expected eight or ten years ago.  The real-world deployments that
 
I am aware of are largely satellite applications run by military and  
government agencies rather than commercial.  But practically speaking, 

any multicast application is a potential multicast security  
application.  And there are point-to-point applications that involve  
groups, which may also need group security.  A multi-point  
teleconference, for example, might benefit from a group security model 

rather than a point-to-point model even if there is a centralized  
control unit with point-to-point connections with the participants.

Mark

On Mar 17, 2005, at 12:03 PM, Roger Khazan wrote:

> A month ago I posted a message about motivation and applications for
> group security. My original message is included at the bottom.
>
> I am still very interested in this topic and would appreciate people
> responding to my message.
>
> So far, I received only two responses. Paul Gilbert and Cesc
> Santasusana told me about the following applications, respectively:
>
> 1. Financial traders, which work together, form groups and supply
and
> receive trade information in these groups. In "large financials you
> often see thousands of sources (traders) and hundreds of groups
(split
> into servers publishing market data
> and traders sending)." Currently, this operation is supported by an
> application from Reuters/Tibco that delivers market data to traders
> and supports these groups. The application uses IP multicast with
> best-effort reliability guarantees. Presently there is "no form of
> security whatsoever for this multicast app."
>
> So, this is a good application for group security. It seems that
> having a central KDS would work here, but the protocols would need
to
> be stateless. Does this make sense? What are the security
requirements
> here?
>
> 2. I am still learning the specifics of this one, but it is about
> supporting decentralized communication in military on-the-move
> environments. For example, there is a need to support secure voice
> conferencing among small groups of people. It is reasonable to
assume
> that initializations (e.g., distribution of keying material) are
> handled by a centralized manager, but "daily operations must be able
> to work without access to the central service."
>
> The environment, scale, and requirements of this application are
very
> different from the first one. It seems that a *non-group* solution
> would work well here: Use a fresh symmetric key for each voice
> conference. Tell participants about this key by encrypting the key
> with each participant's public key. Of course everyone's keys are
> certified by some recognized authority. Instead of using public keys
> all the time, we can also establish some long-term symmetric keys.
> Does this make sense? Maybe it makes sense for groups of upto
certain
> size, but not for larger groups? Can we expect such larger groups in
> this application?
>
> --
> Everyone would agree that research in group and multicast security,
as
> any other research, has to be driven by concrete motivation and
> applications. The information about these is not widely-available or
> is lacking. Let's pull our collective knowledge together and make a
> strong case for this research area.
>
> Looking forward to hearing your thoughts. Thank you.
>
> Roger Khazan
> MIT Lincoln Laboratory
>
>
-----------------------------------------------------------------------

> ---------
> [MSEC] applications and motivation for mcast and group security
> Roger Khazan rkhazan at gmail.com
> Fri Feb 18 12:51:47 EST 2005
>
> I've been reading a lot about multicast and group security and I am
> having hard time finding information about specific applications and
> motivation, especially for decentralized solutions. One application
> that comes to mind is group chat and shared collaborative workspace.
> But there must be others...
>
> I am wondering if people could share with me their thoughts and
> knowledge about *specific* applications that require multicast
> security and group security. Also, which specific applications
require
> (or can benefit from) *decentralized* key agreement solutions? Which
> ones assume *centralized* solutions? I am looking for both
> single-sender and multi-sender applications. Don't limit yourself to
> collaborative applications; maybe there are some involving sensors
or
> multicast tree management, or some military applications? I am
looking
> for specific descriptions, not just general areas.
>
> Are there systems *deployed in the world* today that utilize
multicast
> and group security?  Which ones? Which schemes do they use?
>
> Are there examples in the past where we did not have group security
in
> place, but we wish we did? I'd like someone to make a compelling
case
> why all this stuff is necessary. If you work on designing group
> security schemes, which big problem are you fixing?
>
> Which prototype systems have been implemented and are available for
> download and/or purchase?
>
> Once I get responses from individual contributors, I will compile
this
> information and either send it to the list or provide it to the
> individual contributors. Or, you can post your responses to the
list.
>
> Thank you,
>
> Roger Khazan
> MIT Lincoln Laboratory
> _______________________________________________
> msec mailing list
> [email-masked] 
> http://six.pairlist.net/mailman/listinfo/msec 
>
_______________________________________________
msec mailing list
[email-masked] 
http://six.pairlist.net/mailman/listinfo/msec
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec