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

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

Carl,

Yes, msec must take caution to implement the API without being susceptible
to such attacks as you describe. Your aggregation method is one good
solution. Another way is to have periodic 
rekey message and to aggregate all the membership changes in one rekey 
message per, say, 2 minutes. Other ways are possible too. In any case 
in our model it is the GCKS who is responsible for the rekeying, not the
sender. (The two may be co-located, but that's a different issue.)

> From [email-masked] Fri Jul  6 12:01:49 2001
> 
> 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.

We may have terminology problems here. the GCKS *is* the group owner.
It authenticates members when it talks to them, so there is no issue of 
trustworthiness.

Ran

> carl.

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

---

From: Mark Baugher <[email-masked]>
Date: Sun, 08 Jul 2001 11:32:19 -0700

Ran,

>It authenticates members when it talks to them, so there is no issue of

This is not the model of GSAKMP, GDOI, or the GKM architecture.  A
"policy creation authority" may be used in GSKMP (p.13).   A "Group
Owner" authorizes a member to join a GDOI group (3.2).  In section
3 of GKM architecture, a single group owner is designated as the root of trust.

It is true that the GCKS authenticates members.  But some other authority
authorizes them.  You could say that the GCKS is owned and operated
by the group owner, and that is a legitimate model.  It's also true that the
GCKS or its delegate could be co-resident with a sending member.
But these are special cases of the more general architecture.

For authorization in the more general case, the GCKS acts on behalf of
a variety of authorization applications just as the member acts on behalf
of a variety of security protocols (viz. Figure 3 in
http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt).

Mark