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

From: "David A. McGrew" <[email-masked]>
Date: Tue, 03 Jul 2001 08:54:48 -0400

Ran,

a de-registration mechanism implies a secure channel from each member to the
controller, so I can see your point that it is missing from the architecture.  I
think that it's worth noting that without a secure channel from each member to
the controller, reliable multicast/multi-unicast becomes problematic, since the
KDC has no (secured) information about the loss rates of its messages to the
group members.  This supports the contention that those channels belong in the
architecture, to my mind anyway. 

Having read over the chat on this topic, it strikes me that there are varying
expectations for the lifetime of a group.  Short lived groups have little need
for de-registration, while groups that persisted for a year would likely need a
de-registration mechanism.  A decent analogy may be kerberos tickets, which
can't be revoked like a cert but which can be made so short-lived that it hardly
matters.  I'd venture that the WG is mostly considering short-lived groups. 
IMHO, there are plenty of good reasons for having long-lived groups (most
importantly, to better amortize the registration stage), though I sympathize
with the point of view that our protocols should walk before they run. 

I'd favor noting the possible need for a member-to-controller channel in the
architecture, but not spending much short term effort on realizing it.

David
[email-masked]

Ran Canetti wrote:
> 
> Folks,
> 
> The GKM architecture draft specifies two components of group key management:
> 
> o Registration protocol - this is a *short-term*  unicast protocol between
>   a registering group member and the KDC (or, GCKS).
> 
> o Rekey protocol - this is a protocol where the KDC sends update messages
>   to the group members. The communication in this protocol is typically
>   initiated by the KDC. Furthermore,  typically it will be multicasted.
>   (The should probably be a mechanism within the rekey protocol that allows
>   members to prompt the KDC in case they did not receive the update data in
>   time, but this mechanism does not answer my question below.)
> 
> The architecture does not provide a leaving group member any mechanism
> to let the KDC/GCKS that it has left the group. I'd like to bring up the
> question whether we need to provide such functionality.
> 
> Clearly, in many cases such a "de-registration" protocol will not be
> necessary. A leaving member simply sees itself out and there is no need
> to let anybody know.
> 
> But there may be cases where de-registration is useful: For instance, when
> member pays according to the anount of time it is registered, and this
> amount of time is not known in advance. (Say, in a boxing fight where the
> payment is by the number of rounds watched). In such a case we need to let
> the member *securely* notify the GCKS. This notification will be used to
> update the necessary accounts and to cryptographically remove the member
> from the group (e.g., by updating the OFT/LKH tree in use).
> 
> One possibility would be to push the burden of doing de-registration to the
> application and not deal with it within MSEC. But I think this would be a
> mistake - revoking membership of leaving members is patently a security issue
> that is within the domain of group membership management. So we should not
> leave such "loose ends" to the application. (Also, it seems architecturally
> unwise to have the LKH/OFT module receive its leave requests from a different
> layer than its join requests.)
> 
> So, it appears like we should be adding an optional de-registration
> protocol to the GKM architecture...
> 
> Any opinions?
> 
> Ran
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec

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

---

From: Mark Baugher <[email-masked]>
Date: Tue, 03 Jul 2001 08:03:33 -0700

David,
   Some questions/comments.

At 08:54 AM 7/3/2001 -0400, David A. McGrew wrote:
>ran,
>controller, so i can see your point that it is missing from the 
>architecture.  i

The Registration protocol is a secure channel between member to controller
(which we call KDC in gkmarch and GCKS in SMuG).  I don't understand.
There is no requirement that this channel be torn down.

>kdc has no (secured) information about the loss rates of its messages to the
>group members.  this supports the contention that those channels belong in the

So your concern is that there is no secure multicast channel between the 
member
and KDC?  I think that there may be value of a de-registration function in the
context of re-key for membership management since the KDC has some state
for each member.  Without membership management, the de-registration
protocol boils down to the member establishing a computationally-expensive
channel with the KDC to say the following:  "I am leaving the group; you cannot
stop me from using my keys; you cannot tell if I'm using the keys, but take
my word for it that I'm leaving the group."

Mark

>having read over the chat on this topic, it strikes me that there are varying
>expectations for the lifetime of a group.  short lived groups have little need
>de-registration mechanism.  a decent analogy may be kerberos tickets, which
>matters.  i'd venture that the wg is mostly considering short-lived groups.
>imho, there are plenty of good reasons for having long-lived groups (most
>importantly, to better amortize the registration stage), though i sympathize
>i'd favor noting the possible need for a member-to-controller channel in the
>david
>ran canetti wrote:
> > folks,
> > the gkm architecture draft specifies two components of group key 
> management:
> >
> > o registration protocol - this is a *short-term*  unicast protocol between
> >   a registering group member and the kdc (or, gcks).
> >
> > o rekey protocol - this is a protocol where the kdc sends update messages
> >   to the group members. the communication in this protocol is typically
> >   initiated by the kdc. furthermore,  typically it will be multicasted.
> >   (the should probably be a mechanism within the rekey protocol that allows
> >   members to prompt the kdc in case they did not receive the update data in
> > the architecture does not provide a leaving group member any mechanism
> > to let the kdc/gcks that it has left the group. i'd like to bring up the
> > clearly, in many cases such a "de-registration" protocol will not be
> > necessary. a leaving member simply sees itself out and there is no need
> > to let anybody know.
> >
> > but there may be cases where de-registration is useful: for instance, when
> > amount of time is not known in advance. (say, in a boxing fight where the
> > payment is by the number of rounds watched). in such a case we need to let
> > the member *securely* notify the gcks. this notification will be used to
> > from the group (e.g., by updating the oft/lkh tree in use).
> >
> > one possibility would be to push the burden of doing de-registration to the
> > application and not deal with it within msec. but i think this would be a
> > that is within the domain of group membership management. so we should not
> > leave such "loose ends" to the application. (also, it seems architecturally
> > unwise to have the lkh/oft module receive its leave requests from a 
> different
> > so, it appears like we should be adding an optional de-registration
> > protocol to the gkm architecture...
> >
> > any opinions?
> >
> > ran
> >

---

From: Mark Baugher <[email-masked]>
Date: Tue, 03 Jul 2001 10:23:48 -0700

Hi David,

At 01:08 PM 7/3/2001 -0400, David A. McGrew wrote:
>Mark,
>Mark Baugher wrote:
>then I stand corrected.
>right, I'd assumed that membership management was present (at least 
>optionally).

IMHO, it's a huge gotcha to the implementer to have a protocol that looks 
symmetric
to the registration protocol but which can cause a big performance problem
if it is inadvertently used only with the registration protocol.

>Off topic: does your mailer automatically convert to lower case when it quotes
>nntp messages?

I don't know.  Why do you ask?

Cheers, Mark

>thanks,

---

From: "David A. McGrew" <[email-masked]>
Date: Tue, 03 Jul 2001 13:08:19 -0400

Mark,

then I stand corrected.

> my word for it that I'm leaving the group."

right, I'd assumed that membership management was present (at least optionally).

thanks,

David

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 03 Jul 2001 15:44:25 -0400

Mark, David,

>There is no requirement that this channel be torn down.

Right, so long as your box can handle so many tens-of-thousands of SAs.

I agree though, it is not clear when it is better to let the Cat-1 SA die-off
or which situation requires the Cat-1 SAs to be around as long as
the member is around.  (wie. Which is cheaper: to maintain, or to tear-down
and then re-establish).

Is there's some benefit for the MSEC community to look at the possibility
of maintaining "partial" Cat-1 SAs?  (ie. avoiding complete new negotations
by keeping previous SA state).

thomas
------

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 03 Jul 2001 15:38:07 -0400

David,

>architecture, but not spending much short term effort on realizing it.

Hmm, this brings-up the (old) issue of how long the Cat-1 SA and secure
channel should be around.

If we simply want a 1-to-1 secure channel between the member to KDC,
then we already have this (namely, the Cat-1 SA or
Registration/Initialization).

Even if the "secure channel" was SSL or Ran's IPsec-Tunnel, the question
of the lifetime of the connection remains still.

And you are absolutely correct is stating that the answer depends
on the size of the group (which to my mind is application-dependent,
and to a some extent depends on the availability of a distributed KDC).

I think it is the application that will decide the type of data, speed,
capacity or routers/KDCs to hold SAs, etc.

thomas
------