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

From: Ran Canetti <[email-masked]>
Date: Sun, 1 Jul 2001 19:09:29 -0400

Thomas, Mark,

I think you misunderstand my intention regarding the de-registration protocol.
So let me try to clarify. The de-registration protocol is a tool that allows
the leaving member to securely notify the GCKS that it has left the group. 
There is no mechanism that forces the GCKS to rekey the group immediately 
or at any other time. This is up to the GCKS to decide, and is not up to 
us for standardization. (True, the design we have in mind would  call for
the GCKS to remove the member from the group in the next rekeying message.
But this is again up to the GCKS.)

My reason for making the de-registration  protocol an (optional) part of the
msec suite is to provide the application with a complete and uniform interface 
of secure group operations. This looks cleaner and better design to me than 
forcing the application to take care of securing leave operations by itself.

In all, I see two options:

1. We believe that having members sign up only for preset periods 
of time is sufficient for now. In this case we can indeed leave 
de-registration for later. However, as Sandro noted, in this case there 
is much less need in the rekeying mechanism in the first place. Instead we 
can use the MARKS mechanism (or simply choose keys for preset periods of 
time) and avoid the rekeying messages altogether. 

2. We decide that we need to provide the group controller with the ability 
to let members sign up for an unspecified time and then be charge them 
according to the actual amount of time used. In this case it is clear that
secure de-registration is necessary. Here I strongly believe that we need to
provide this functionality within msec.

Ran

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

---

From: "Sandro Rafaeli" <[email-masked]>
Date: Mon, 2 Jul 2001 11:17:20 +0100

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 02 Jul 2001 08:01:07 -0700

Hi Ran
   the model I have in my head of a group key management protocol is
a protocol that operates on security association databases of the
communicating endpoints:  The group key management protocol causes
SAs to be created, modified, and deleted.  If a protocol is added that
does not do any of these things, then it does not look like a "better and
cleaner" design to me at all.  It looks muddled to me.  In the case of
de-registration without an LKH tree, it looks like there is an expensive
operation that has no point at all.

   Your example of using the key management protocol to measure the
time that someone is in the group underwhelms me because this
function surely would be provided by the authorization application that
is telling key management what to do and not do.  That is, the member
will tell the authorization app that it is leaving the group and the 
authorization
app will tell key management to re-key the group.  Similarly, if the member
does not report anything but is discovered to be a spy or a deadbeat, the
authorization system will tell key management to re-key the group to
remove the particular member.

   There is no need to put the de-register function into group key management.
Your example is a rather specific and detailed electronic commerce
example - a pay-per-time example.  Keep in mind the kind of abstractions
that we work with in key management.  We have a 32-bit group identifier,
or a network address, or email address, but nothing that could describe a
subscription group called "Friday Night Fights" which has an option where
you can pay for the time watched of a particular fight.  It is clear in your
example that there is a commerce application that is mapping key
management constructs to something much more complicated.  This is
where the time measurement belongs, not in the lower-layer services
like key management.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 02 Jul 2001 14:06:11 -0400

Ran,

I understand that we have have a "cleaner" interface, though there
is a cost to this cleanliness, namely an increase in the complexity
and (possibly) state maintained by the KDC and the client-software.

If we over-spec MSEC, then it would be harder/longer for people to
implement the spec.  Most vendors want to use/implement a simple
and practical spec.

>provide this functionality within msec.

We are not arguing about the need of this functionality, but *where* this
functionality should reside.

I think it is an application layer functionality.

thomas
------