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

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

Mark,

you wrote:

> >I agree that implementing the de-registration can/should be postponed
> >until we have things working. But I do think that we should keep it in mind
> >as a potential functionality of the msec protocol suite.
> >
> >let me try to summarize the points against leaving it to the application:
> >
> >- It will force the application to set up its own secure channels between
> >each member and the GCKS. This would be done in addition to the msec secure
> >channels, will require its own negotiations, policy, etc. Why burden the
> >application with all that?
> 
> I think it's unavoidable.  It's not that bad since SSL, SET, or other
> protocols
> may be better suited to the purpose and, in the case of SSL, it is widely
> available.  This is true for trust (e.g. certificate management) and other
> services that may be need for some key management applications.

I disagree. If we design things right then there will be no reason for the 
member application program to set up a secure connection with the GCKS
aside from what msec does. Requiring the application to do this redundant
security overhead undermines the usability of msec. If the application
has to do security by itself then it has good incentive to bypass
msec altogether...

> 
> 
> >- It will force us to set up a way for the msec module in the GCKS to
> >receive
> >leave operations from the application module. This will complicate the
> >interface of the msec module inside the GCKS.
> 
> What's the "msec module?"  In GDOI, there is an authorization interface
> (as there is in IKE and other key management systems).   For GDOI,
> this interface is where key management gets told to send a Re-key
> message.  There is zero overhead here.

If the application prorgam within the member sends a de-registration message 
to the application program in the GCKS then the latter should notify the 
msec "layer" (or, "module") that the member has left and should be removed
from the LKH/OFT tree. This last notification is part of the interface
between the msec module/layer and the outside world.

> 
> 
> >- It will disallow joining the de-registration operation with other msec
> >operations (such as sending the de-registration message over a long-lived
> >msec secure channel).
> 
> There is no de-registration message and there should not be one in my
> opinion.  I think this is the crux of cfm's posting, if I read it right.

The premise of this discussion is that we're in the
pay-until-you-say-enough model. In this model the member has to somhow
notify the GCKS that it has left (otherwise it will keep paying). 
I call this notification the "de-registration message", in whatever layer it
takes place.

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:33:40 -0400

Ran,

(see in-line comments)

>has to do security by itself then it has good incentive to bypass

Its not clear to me that the member application needs to talk to the 
GCKS, if the member application no longer wants to receive the 
content to which he is subscribed, he'll have to leave that multicast 
group. A vigilant multicast provider, listening to the IGMP 
all-routers group, will know which hosts have left and can notify the 
GCKS (if he desires). Since the GCKS is operating on behalf of the 
content provider/group owner, I don't see any problem with this 
model. We will have a GCKS to group owner connection in either case; 
in my scenario originated by the group owner exercising control of 
the GCKS; in your scenario originated by the GCKS providing 
membership updates to the group owner. I'm not sure either one is 
more complicated, though it seems (just seems) to me that what we are 
trying to do is redundant with other activities necessary for the 
efficient operation of the multicast system.

>between the msec module/layer and the outside world.

Having not seen an API for the MSEC module, I can't comment on 
whether the addition of a resignation interaction is a problem for 
the user or not. I thought that one aim of the current MSEC approach 
is to closely follow the IPSEC APIs. I guess we could map a "delete 
key" to a "resign" at the interface, though "delete key" is local, 
and "resign" has network traffic implications.

Now that I start thinking about it. How are we to deal with a group 
whose natural life has ended? A content application finishes, and 
notifies all subscribing members (i.e. broadcasts) that "the 
broadcast day has ended", will each application issue a "delete key" 
to the local MSEC, causing a flood of resignations? Is that what we 
want?

>I call this notification the "de-registration message", in whatever layer it

In the "pay-until-you-say-enough" model, it should be the using 
application which notifies the sending application that it's had 
enough, I would put the burden on the sending application to key-out 
any folks who it wants to ensure are off the air. Alternatively, as I 
mention above, if it is monitoring the leaves and joins it can leave 
the key in place (make it easy for the customer to "tune in" again) 
and start charging when he sees them re-join the multicast group.

>Ran

carl.

---

From: Mark Baugher <[email-masked]>
Date: Fri, 06 Jul 2001 09:04:13 -0700

Hi Ran

At 12:56 AM 7/6/2001 -0400, Ran Canetti wrote:
><snip>

We're not talking about setting up a secure connection with the GCKS but
with the thing or things that control the group key management - these
entities may or may not be co-resident with the GCKS.  Figure 2 of
http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt
draws us a picture.  There is a block labelled "AUTHORIZATION"
in Figure 2.   Hugh pointed out that policy must be enforced at
the member so Figure 2 should probably show AUTHORIZATION there
as well as at the GCKS.  This AUTHORIZATION app acts on behalf of
the Group Owner and controls application-specific things like accounting
in an IT environment, billing in a commercial environment, clearing for
DRM, intrusion detection, etc., as well as group key management.
Our concern is with the block labelled "GKM" in Figure 2.  Application-
specific processing like when a member ceased using a key is
outside of GKM, which has no idea what a security protocol
implementation is doing with a key that GKM copied into its space.  To
remove a member, something must tell the GKM to Re-key the group using
membership management (LKH) and that's got to be AUTHORIZATION.

If there is any need for a member to ask the GCKS to Re-key it out
of a group, then this should be considered in conjunction of the Re-key
protocol, not the Registration protocol.  I think we should move on to
discuss the Re-key protocol, which needs to be considered by the WG.
With all the talk about policy and de-registration, we have overlooked
the most important change proposed in
http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt
and that is the idea of putting a Re-key protocol specification on a
separate standards track.

We have probably explored this issue of de-registration to the point
where we should agree to disagree - for now.

Mark

---

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

Ran,

Rather than handwaiving "design things right", why don't you write a draft
to address the Deregistration SA management and key management.

I would be happy to review it once you finish writing the draft.

thomas
------

---

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

Carl,

At 7/6/2001||08:33 AM, Carl F. Muckenhirn wrote:

>Its not clear to me that the member application needs to talk to the GCKS, 
>if the member application no longer wants to receive the content to which 
>he is subscribed, he'll have to leave that multicast group. A vigilant 
>multicast provider, listening to the IGMP all-routers group, will know 
>which hosts have left and can notify the GCKS (if he desires).

This is an interesting question.  Do we define "group membership"
as IGMP-membership (which in IGMPv2 does not carry any host identity)
or as Application-layer membership.

I think this notion will best work in IPv6 Neighbour Discovery
or in IPv6 MLD.

>Since the GCKS is operating on behalf of the content provider/group owner, 
>I don't see any problem with this model. We will have a GCKS to group 
>owner connection in either case; in my scenario originated by the group 
>owner exercising control of the GCKS; in your scenario originated by the 
>GCKS providing membership updates to the group owner. I'm not sure either 
>one is more complicated, though it seems (just seems) to me that what we 
>are trying to do is redundant with other activities necessary for the 

As far as I understand it, the GCKS/KDC works at a different (parallel)
plane to IGMP.  Thus, in fact, the GCKS may not be a member and thus
not within the multicast distribution tree.

Even if the GCKS was on the multicast distribution tree it will never
see anyone's IGMPv2 (or IGMPv3) Report messages, as these are
only seen by the subnet (multicast) router and are never propagated
upstream.  The router only send a "join" or "prune" upstream.

thomas
------