Subject: RE: [MSEC] De-registration protocol?

From: Ran Canetti <[email-masked]>
Date: Thu, 5 Jul 2001 16:28:59 -0400

I agree.

Ran

> From [email-masked] Thu Jul  5 15:32:15 2001
> 
> It seems to me that this question of business model has nothing at 
> all to do with key management. One could just as easily saddle the 
> multicast transport system with these requirements. (Seems we are 
> falling into the typical security trap of "well no one else is doing 
> it, why not security!")
> 
> Ran's comment on mitigations, points the way to a solution, use an 
> application service to manage the billing. One could then effect 
> their service delivery decisions through key management. That seems 
> much more straightforward than trying to effect billing decisions 
> through key management.
> 
> carl.
> 
> On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote:
> 
> 
> >Sandro, you're right that this business model of pay-until-you-say-enough
> >is susceptible to this type of failures. This is indeed something that the
> >application will have to deal with... but this business model seems to be
> >attractive in some cases nonetheless. (one way to mitigate this is to put
> >a cap on the payment amount,  on the duration, etc. for instance in a boxing
> >show you never pay more than the full 12 rounds.)
> >
> >Ran
> >
> >>  From [email-masked] Mon Jul  2 06:18:31 2001
> >>
> >>
> >>  Ran,
> >>
> >>  Applications are prone to crash when you least expect :(. When that occurs,
> >>  paying members may pay much more then they are supposed to for the simple
> >>  reason that the de-registration/leave command was never issued.
> >>  De-registration/leave command is not enough to control the time a member is
> >>  participating in the group...
> >>
> >>  Sandro.
> >>
> >>  |  BTW, Mark, in a model where a member pays acording to the
> >>  |  time elapsed
> >>  |  between registration and de-registration, the
> >>  |  de-registration mechanism
> >>  |  is not just for being nice. And this is true regardless of how these
> >>  |  protocols are called...
> >>
> >>
> >
> >_______________________________________________
> >msec mailing list
> >[email-masked]
> >http://www.pairlist.net/mailman/listinfo/msec
> 
> 
> -- 
> Carl F. Muckenhirn
> Division Manager
> SPARTA, Inc.
> Security Engineering Division
> 9861 Broken Land Parkway, Suite 300
> Columbia, Maryland  21046
> 410.381.9400 x208
> 410.381.5559 (fax)
> 
> 

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

---

From: Ran Canetti <[email-masked]>
Date: Fri, 6 Jul 2001 21:51:59 -0400

Thomas,

As I said, my impression is that it would end up being both simpler and 
more secure to handle the de-registration on the msec level rather than 
leave it to the application. (in particular, this does not require 
long-lived SA's between the KDC and each member.)

Nonetheless, I very much agree with you that the de-registration issue is 
only part of a larger issue: what functions whould the msec suite provide,
and what should the API of msec look like. So let's postpone this doscussion
to when we discuss the larger picture of requirements/API. (Cathy Meadows, 
Paul Syverson  and I are currently working on a first draft of an msec 
requirements document. When its ready the working group will be invited 
to bite into it and tear it apart...)

Ran

> 
> I think you are confusing the concept of a member at the IGMP-level and
> at the Application-level.
> 
> At the expense of repeating myself, key management for MSEC would be
> made extra complex if the KDC is required to maintain (extra) SAs just
> for a uni-directional "quit" message from a member.
> 
> Now, if a given Application (eg. PPV) wants to have a Deregister message,
> then the key management implementation within that Application
> can *augment* the BASE Msec Key Management protocol with additional
> keys, SAs and other parameters.
> 
> Alternatively, the Application-program the member-client can send
> an Application-layer or Transport-layer "quit" message (digitally signed),
> directed for processing at the KDC's Application-layer or Transport-layer.
> This approach is outside msec-key-management, and provides the best
> flexibility.
> 
> 
> thomas