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

From: Ran Canetti <[email-masked]>
Date: Sat, 30 Jun 2001 00:25:18 -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.
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.

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

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.

Ran

The question is what functionality we want msec to provide. if we want msec
to support groups where 
> From [email-masked] Fri Jun 29 19:17:05 2001
> 
> Ran
>     Why wouldn't the service operator use a secure electronic transaction
> protocol?  A group key management protocol operation would only
> be meaningful if it was a rekey-me-out-of-this-group operation.  I
> don't know why a member would not just delete its keys and
> leave the group that way.  This is how we want them to do it for
> large-scale source-specific multicast applications, isn't it?  If the
> member's group key management performs a rekey-me-out-of-this-group,
> it does not mean that the member has destroyed the keys.  It does
> not mean that the member is not continuing to use the keys. It is
> just a notification from the member to the KDC that the KDC can
> re-key the member out of the group.  The KDC might then run LKH
> or some other membership management algorithm over Re-key
> messages to change everyone's key except the member that sent
> the rekey-me-out-of-this-group request to the KDC.  That's the only
> way to remove access to key material (e.g. future TEKs)  encrypted in the
> group KEK.  There is no way to remove access to data security TEKs
> that were disseminated prior to the rekey-me-out-of-this-group request.
> 
> De-registration protocol has questionable use as a
> a mechanism to trigger an LKH message removing the member
> from the group.  A key-management protocol is not needed to do this,
> in my experience, an application-programming interface to the
> KDC can allow an ecommerce/authorization application to do this.
> 
> If some vendors ask for this, I think we should revisit the idea of
> doing a deregistration/rekey-me-out-of-this-group protocol message.
> Otherwise, msec key management has enough on its plate:
> Simple systems are more secure than complex ones.
> 
> Best Regards, Mark
> 

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

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 22:21:42 -0700

Ran

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

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

>updating databases that are under msec control (such as LKH/OFT).

This is where rekey comes into play, as I mentioned above.

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

Best Regards, Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Sat, 30 Jun 2001 16:44:21 -0400

Ran,

I still think that the notion of De-registration and Registration
are NOT symmetric.

This asymmetricity is due to the fact that in the architecture, *control*
is not symmetric or shared.  That is, a group member cannot decide
when to re-key the group (that's the KDC's decision).

A member can wish it could effect a re-key (by sending a quit message),
but the decision is still the KDC's (and is a function of the
application area).  It may be the case that it would be cheaper
to ignore a member's quit-message, and wait until the next
periodic-rekey.

A group key management protocol will not function without a Registration
process, though it will function without De-registration.
This is true for GDOI and GSAKMP as they stand today.

If we are going to add text to the architecture-doc about de-registration,
I would also like to insist that the text mentions De-Registration
as being very likely an Applicationlayer function.

(I'm having difficulty with this "chair-hat-on/hat-off" business :)

cheers,

thomas
------