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

From: "Sandro Rafaeli" <[email-masked]>
Date: Sun, 1 Jul 2001 18:27:11 +0100

The "waste" left in the LKH tree can do more damage to group members than it
does to the KDC. If leaving members are not removed from the LKH tree, then
the tree will be getting higher and higher, causing the number of keys held
by members to increase. Not only that increases, but the computation
required per rekey message also increases. The original idea of LKH-like
protocols is to minimise bandwidth usage and members and KDC storage. That
is a fair reason for maintaining a tight control of the group membership.

Mark said that the de-registration (or whatever it's going to be called, if
ata ll :)) is required only in conjunction with a rekey protocol. I would
extend that to: de-registration is required only when membership management
algorithm are employed!! If a unique Group KEK is being used, then there is
no (clear) reason for the member to tell the KDC he has left the group. A
future rekey in this case will not consider the leaving members for the
simple reason that it is not possible to remove old members with a unique
Group KEK (unless you want to encrypt the new KEK and TEK(s) with every
remaining member's secret key.

Cheers,
Sandro.

ps: Thomas proposed "a De-registration-KEK" to authenticate the leaving
member's de-registration command. In order to save that "extra" key, what
would the implication of using the current member's secret key (known only
by himself and KDC) for that purpose?

|  -----Original Message-----
|  From: [email-masked]
|  [mailto:[email-masked]]On Behalf Of Mark Baugher
|  Sent: 01 July 2001 00:43
|  To: Ran Canetti
|  Cc: [email-masked]; [email-masked]
|  Subject: Re: [MSEC] De-registration protocol?
|
|
|  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

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

---

From: Mark Baugher <[email-masked]>
Date: Sun, 01 Jul 2001 11:27:12 -0700

>is a fair reason for maintaining a tight control of the group membership.

The KEKs (leaf and node in the LKH case) will always have a lifetime and will
expire.  The KDC can reduce memory consumption and message-bandwidth
by making the lifetime shorter.  In so doing, it must endure more frequent
"registrations" (GDOI Phase 2, GSAKMP Group (re-)Establishment),
which impose a computation hit on the KDC.

>algorithm are employed!! If a unique Group KEK is being used, then there is

Yes, this is what I meant though it's not what I wrote.

>no (clear) reason for the member to tell the KDC he has left the group. A

If there is only a single KEK or no KEK then this is true.

>remaining member's secret key.

So I amend what I wrote as follows:

It would be a REQUIREMENT for a "de-register" operation that it MUST NOT
be used when there is no LKH-like membership management algorithm
used for the group.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 02 Jul 2001 12:17:55 -0400

>by himself and KDC) for that purpose?

Sandro,

This was only a suggestion and illustration as to the complexity
of the notion at the key management layer.
If that member already shares a secret-key with the KDC, this this
extra Deregister-KEK may be redundant.

The real issue is not simply the key, but the SA-management
surrounding that deregistration key.

thomas
------