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

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

Carl,

Indeed, you touched upon an important issue, which is probably the crux of
this discussion: what should be the API of the msec protocl suite?
This is something for us (msec) to decide, and it is indeed a delicate
issue...  In particular, we have to keep the API in mind when discussing the 
placement of the de-registration message.

As I see it, as far as "leaving a group" goes, the msec API within a member
should allow for to different "leave" instructions:

  1. "Silent leave". Here the application tells msec that the member wishes
  to just stop listening to the group. Here there is no need in notifying the
  GCKS, only to reset local variables.
  
  2. "De-registration" (or whatever better name we'll find for this
  instruction). Here msec is required to explicitly notify the GCKS that a
  member has de-registered. This requires communication with the GCKS, 
  in one way or another. 
  Once the msec module inside the GCKS receives such a communication from 
  the msec module inside the member, it will do two things:
   - update its local state (eg, the LKH/OFT tree)
   - notify the application that the member has de-registered.
  
  This instruction will be useful, for instance, for applications that 
  use pay-until-you-say-enough billing.

It is up to the application to decide which of the two instructions to 
make. Msec should (eventually) be able to deal with both instructions. 

Ran

> From [email-masked] Fri Jul  6 08:18:57 2001
> 
> Ran,
> 
> Let me clarify my position.
> 
> If the purpose of the "De-registration protocol" is to accomplish 
> business requirements, beyond key management, such as suspension of 
> billing or ceasing transmission of content, then I don't think the 
> Key Management System is the appropriate place for it. If the purpose 
> of the "De-registration protocol" is to support the correct or 
> efficient operation of the Key Management System, and use of that 
> protocol supports the business needs of the overall Business 
> Management System, then I would support its inclusion in the Key 
> Management System.
> 
> Now I'm still agnostic as to whether there is a valid key management 
> reason for members to notify the group (or the group controller) that 
> they are resigning, unless the Key Management System will be doing 
> something about it (such as issuing a compromise recovery event to 
> ensure that the departing member has actually departed).

If msec wants to accomodate applications that use  pay-until-you-say-enough
billing, then it should indeed issue such compromise recovery event when 
a member leaves.

> 
> In looking at your description below, are we asking the multicast 
> application to distinguish between "de-registration" and "leaving" 
> the group. For example, if you have an "internet tuner" which can 
> "tune in" to different multicast channels, will moving from 
> "SHOWTIME" to "HBO" cause the local MSEC implementation to 
> "de-register" from SHOWTIME, and register with HBO, or will the 
> application be smart enough (and bother the user enough) to know that 
> changing the channel was not the same as "de-registering"?
> 
> In the described scenarios, who is actually doing the IGMP 
> join/leave? Has that been added to MSEC, or is it in the application? 
> When we look at the effect of a GKM "resignation" (I think that word 
> is much better than "de-registration"), it only makes sense if it is 
> done in concert with other communications and application actions, 
> otherwise we've just made the system unstable, or non-responsive 
> (things which security applications are too often accused of).

As I said above, the application should have the choice to either leave
silently or to explicitly "resign" or "de-register". IT is up to the
application to decide which one to use. Msec should be able to accomodate
both.

> 
> carl.
> 
> On 7/6/01 at 12:54 AM -0400, Ran Canetti wrote:
> 
> 
> >Carl, Mark,
> >
> >I think I was too hasty in agreeing and didnt read Carl's note thoroughly
> >enough.  What I agreed to was the idea that the issues brought up by Sandro,
> >i.e., the inherent reliability problems associated with the
> >pay-until-you-say-enough model, are best dealt with by the application.
> >
> >On second reading, however, it seems that you may have meant that the entire
> >de-registration operation is best done at the application layer. Here I beg
> >to differ:
> >
> >It is very true that the de-registration operation is driven by a request
> >of the application *within the group member*. The natural place for this
> >request to go is to the msec "layer" (or, "module") within the member.
> >Then the msec layer within the member will do what is needed,
> >ie, transmit this request securely to the msec layer within the GCKS.
> >The msec layer within the GCKS will then notify the application
> >layer within the GCKS (eg, the billing center) that the member has
> >de-registered.
> >
> >Pictorially, this would look like:
> >
> >
> >
> >        GCKS                                    MEMBER
> >
> >      |--------|                             |----------|
> >      |        |                             | multicast|
> >      | applic.|                             | applicat.|
> >      |        |                             |          |
> >      |--------|                             |----------|
> >          ^                                        |
> >          |                                        v
> >      |--------|                             |----------|
> >      |        |     de-registration         |          |
> >      | msec   | <------------------------   |  msec    |
> >      |        |                             |          |
> >      |--------|                             |----------|
> >
> >
> >Ie, the flow of information starts at the top right box and goes
> >clockwise from there. The other suggestion as I understand it is:
> >
> >        GCKS                                    MEMBER
> >
> >      |--------|                             |----------|
> >      |        |     de-registration         | multicast|
> >      | applic.| <------------------------   | applicat.|
> >      |        |                             |          |
> >      |--------|                             |----------|
> >          |                                        |
> >          v                                        v
> >      |--------|                             |----------|
> >      |        |                             |          |
> >      | msec   |                             |  msec    |
> >      |        |                             |          |
> >      |--------|                             |----------|
> >
> >
> >This seems worse in my eyes, for the reasons I listed in my previous note.
> >
> >
> >Ran
> >
> >
> >>
> >>  From [email-masked] Thu Jul  5 16:29:01 2001
> >>
> >>    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
> >>  > >
> >
> >
> >_______________________________________________
> >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: "Carl F. Muckenhirn" <[email-masked]>
Date: Fri, 6 Jul 2001 11:59:29 -0400

Ran,

Yes I see the usefulness in the local host of the two types of API 
interactions. Now the question is what happens with them.

As you note in-line below, a CR event is a valid way to accomplish 
the providers aim of only providing traffic to paying customers. What 
I don't want to see happen is for users to resign, and immediately 
cause a CR event (think of the mischief one can wreak), I really see 
the resignation being a message from the user's multicast 
application, to what ever management application is operating the 
broadcast, that management application would be able to 
schedule/cause CR events, of his choosing, at times of his choosing 
(e.g., we've had 100 resignations, lets key them out).

Again, I don't see a real need for the member to tell the GCKS that 
he's out (the GCKS really can't do anything about it), because any 
action the GCKS takes is now at the bidding of the (potentially) 
un-trustworthy member rather than the trustworthy group owner.

carl.