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

From: Ran Canetti <[email-masked]>
Date: Fri, 6 Jul 2001 00:54:52 -0400

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

---

From: "Carl F. Muckenhirn" <[email-masked]>
Date: Fri, 6 Jul 2001 08:18:49 -0400

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).

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).

carl.

-- 
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)

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 06 Jul 2001 15:14:44 -0400

Ran,

I will persist on addressing the De-Registration protocol, since I think
it will have great impact on the overall key management architecture.

>layer within the GCKS (eg, the billing center) that the member has

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
------