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

From: Ran Canetti <[email-masked]>
Date: Sat, 30 Jun 2001 10:07:57 -0400

Mark,

> >The purpose of the de-registration protocol is to allow a member to notify
> >the GCKS that he is no longer interested in being a member.
> 
> Yes it is. But what we don't know is if the leaving member is going to
> continue to use its keys.  The GCKS can only assume that it is and rekey
> the group.

That's exactly the point: The de-registration message will typically 
prompt some action by the GCKS to make sure that the leaving member 
indeed loses access to the group communication. (This may take the form of 
updating the LKH/OFT tree or doing whatever is necessary.)
That's why the de-registration message is an integral part of the 
msec protocol suite, if it used.

> 
> >This would be important in the scenarios i described where members dont
> >know
> >in advance whn they'll leave and pay relative to membership time.
> 
> This sounds like a secure electronic transaction to me and not a key
> management protocol operation.

It is no more (and no less) a set than the registration protocol. 
in both cases, there are: 
- financial/accounting consequences, with the usual authentication an
  non-repudiation requirements. 
- group key management consequences (eg, updating the LKH/OFT tree, and/or
  downloading keys+policy token).

> >if a de-registration functionality is necessary then it should be done
> >within msec, just like the registration, since it has security implication
> >on the group. this is because the de-registration would typically involve
> >updating databases that are under msec control (such as LKH/OFT).
> 
> This is where rekey comes into play, as I mentioned above.

Rekey is where the updated tree is manifested. But we need some way to
prompt the GCKS to update its tree. This will be done by the de-registration
protocol. 

> >That said, I agree with you and Brian that we can leave the detailed
> >specification and implementation of the de-registration protocol to a
> >later time (unless people feel that it is important to specify it at this
> >time). Still, I would add language to the GKM architecture document
> >regarding the role of this protocol.
> 
> I'm not sure what Brian is recommending.  I recommend leaving the
> decision to a later time.  I think we have not decided to do a Registration
> protocol as a WG.

No, it is under discussion.

Ran

> Best Regards, Mark
> ?

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

---

From: Mark Baugher <[email-masked]>
Date: Sat, 30 Jun 2001 16:43:04 -0700

Ran
   I have not heard any support on this list for the de-registration protocol
so I would not rush to say it's a an "integral part of the msec protocol
suite."  It's something we're discussing, but I think the costs outweigh
the benefits.

First, it's use is complicated.  For example, it is a REQUIREMENT that
you use the de-registration protocol only if you use the re-key protocol.
One might expect that if you do a register, then you might do a
de-register, but this is a waste of resources unless it is possible to
rekey some member out of the group.

Someone pointed out that the name "register" is a problem since it's
an overloaded word.  It's a metaphor really that conjures up a lot of things
outside the scope of key management.  I think we ought to change the
name of "register" and go back to GSAKMP or GDOI.  We called the
GDOI IKE Phase 2 the GROUPKEY-PULL exchange; GSAKMP uses
"Group Establishment."  I can't help but think the word "register"
invites a "de-register," which is not meaningful outside of the context
of re-key.

Another problem with de-register is that key management should not
be re-keying the group on a member's signal.  There is an authorization
application that controls the group and not the members.  About all
the de-register protocol will do is to alert the authorization app that
a member claims it has left the group.

There is exactly one benefit to doing de-register:  For a KDC that has
a LKH or some other structure to maintain group membership, a
de-register allows a member to be nice and inform that KDC that
it can release some memory that is currently allocated for that
member.  How much memory would that be?  128 bits plus some
metadata I suspect.  No very much at all.

I think we should drop the notion of a "de-register" operation and take
up the issue of members announcing that they are leaving groups in
the re-key protocol work.  If it belongs anywhere, that's where it
belongs.  It really has nothing to do with register independent of
re-key.

Mark