Subject: [MSEC] De-registration protocol?

From: Ran Canetti <[email-masked]>
Date: Thu, 28 Jun 2001 15:48:15 -0400

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

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jun 2001 08:46:15 -0400

Ran,

Here are some comments on the notion of de-registration
in the context of the key management work in MSEC.
Please do read them (and possibly respond).

>question whether we need to provide such functionality.

Most of the applications I have come across want to make use
of single-source multicast to deliver content in a Pay-Per-View
model where the unit of content or time is pre-programmed in advance
by the content provider.

Thus, in this common model, the content provider leaves it up to the
user/customer to decide the unit of content to buy and to purchase
additional units when needed. Thus the burden is on the user.

Citing the CableTV example, from a revenue perspective the content provider
would like the user to pay for an entire unit of content (eg. whole movie) 
even when the user does not consume all of it.  We've all had the
experience buying a lousy movie in a hotel :)

>from the group (e.g., by updating the OFT/LKH tree in use).

The example you quote seems contradictory.  If a user is unsure about
the number of rounds he needs to watch (to complete the entire match),
the he/she can buy the programme one-round-at-a-time.

If the user fails to pay for the next round of programme, then the user
is left out.  It matters little (to the system) if the user says good-by
before the completion of the match or of the paid unit.

If anything, it is the other way around:  the system reminds the user
that the user only has X minutes left before the unit of content is over,
and for the user to pay some more.

>layer than its join requests.)

Again, this depends on the application model (ie. system-initiated or
user-initiated membership-termination).

I don't think it is a mistake to leave it to the application.
In fact, it makes more sense to let the application-area decide which
model to follow (system-initiated or user-initiated).

In the specific case of MSEC key management, requiring the member
to specifically de-register has the following implications:

  - How is the member going to de-register (ie. what mechanisms):

    If the member has to send a de-register message through the Cat-1 SA,
    then that Cat-1 SA has to be around as long as the member is registered.
    Now, this is an unresolved issue:

      Do we keep a Cat-1 SA around just so that the member can send
      one message (de-register) to the GCKS?
      This causes a lot of state to have to be maintained at the GCKS.

      Do we let the initial Cat-1 SA die, and establish a new Cat-1 SA
      just for the member to send one message (de-register)?
      This is a lot of negotiations and cycles just for one message.

  - Authentication of de-register message:

    Clearly this de-register message has to be source-authentic, otherwise
    any member can de-register other members.

    This points to the need of the members to have certificates (which
    they do anyway, in order to register in the first place, both
    in GSAKMP and GDOI).

    Since we assume that the Application triggered the initial Register
    message (digitally signed), then it make it makes sense to let
    the Application decide (and send) the final de-register message (with
    a digital signature).

  - Reliability:

    In SMuG and MSEC we all concluded that reliability of key management
    messages should not have to be dealt by the key-management-protocol.

    Now, if you insist that the de-register message must be part of
    the key management protocol, then you also must provide it
    with reliability.

    Simply saying that "some layer above" will provide it with reliability
    is really insufficient (circular argument).

    However, it makes sense to say that the Application (or a transport-layer
    mechanism) will provide/assume reliability.  Which, again, points
    to appropriateness of the de-register message at the Application layer.

thomas
------

---

From: "Sandro Rafaeli" <[email-masked]>
Date: Fri, 29 Jun 2001 14:55:50 +0100

Hello everyone,

I'd like to introduce myself: I am Sandro Rafaeli and I am a 3rd-year PhD
student at Lancaster University, UK. My research topic is secure group
communication.

First of all, I apologise for my intrusion!

I agree with Thomas, when he says that a KDC using MARKS does not need to
know whether the member, which has paid to watch an event, is really
watching it or not. This will not change the key value for a given time
slot. In MARKS, membership changes do not force key changes. But, what
happens with a KDC using OFT/LKH? If a KDC has at some time 10 thousand
*registered* members, and 5 thousand of those members leave, and after that
other 5 thousand join the group. If there is no *leave* protocol, it seems
to me that the KDC will be holding 15 thousand member nodes... Bottom line:
When is the OFT/LKH database cleaned up?

As I see the architecture at the client-side, there is an application that
requires secure communication and there is the GKM-module that uses a
GKM-protocol to get the required keys from the KDC. It seems to me that it
is the application that requests to the GKM-module to register with the KDC
(the module cannot decide it by itself). The same occurs when the
application is being shutdown: it should request to the GKM-module to
de-register from the KDC. As Thomas has noted, this raises the issue of how
to actually send the authenticated *leave* command to the KDC, since the
Cat-1 SA has already been closed... Then, again, what happens if the
application is not properly shutdown (it may stall or the machine is turned
off). How does the KDC clean up its key database?

Sandro.

|  -----Original Message-----
|  From: [email-masked]
|  [mailto:[email-masked]]On Behalf Of Thomas Hardjono
|  Sent: 29 June 2001 13:46
|  To: Ran Canetti; [email-masked]
|  Subject: Re: [MSEC] De-registration protocol?
|
|
|
|
|  Ran,
|
|  Here are some comments on the notion of de-registration
|  in the context of the key management work in MSEC.
|  Please do read them (and possibly respond).
|
|
|  At 6/28/2001||03:48 PM, you 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.
|
|  Most of the applications I have come across want to make use
|  of single-source multicast to deliver content in a Pay-Per-View
|  model where the unit of content or time is pre-programmed in advance
|  by the content provider.
|
|  Thus, in this common model, the content provider leaves it up to the
|  user/customer to decide the unit of content to buy and to purchase
|  additional units when needed. Thus the burden is on the user.
|
|  Citing the CableTV example, from a revenue perspective the
|  content provider
|  would like the user to pay for an entire unit of content
|  (eg. whole movie)
|  even when the user does not consume all of it.  We've all had the
|  experience buying a lousy movie in a hotel :)
|
|
|
|  >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).
|
|  The example you quote seems contradictory.  If a user is unsure about
|  the number of rounds he needs to watch (to complete the
|  entire match),
|  the he/she can buy the programme one-round-at-a-time.
|
|  If the user fails to pay for the next round of programme,
|  then the user
|  is left out.  It matters little (to the system) if the user
|  says good-by
|  before the completion of the match or of the paid unit.
|
|  If anything, it is the other way around:  the system reminds the user
|  that the user only has X minutes left before the unit of
|  content is over,
|  and for the user to pay some more.
|
|
|
|  >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.)
|
|  Again, this depends on the application model (ie. system-initiated or
|  user-initiated membership-termination).
|
|  I don't think it is a mistake to leave it to the application.
|  In fact, it makes more sense to let the application-area decide which
|  model to follow (system-initiated or user-initiated).
|
|  In the specific case of MSEC key management, requiring the member
|  to specifically de-register has the following implications:
|
|    - How is the member going to de-register (ie. what mechanisms):
|
|      If the member has to send a de-register message through
|  the Cat-1 SA,
|      then that Cat-1 SA has to be around as long as the
|  member is registered.
|      Now, this is an unresolved issue:
|
|        Do we keep a Cat-1 SA around just so that the member can send
|        one message (de-register) to the GCKS?
|        This causes a lot of state to have to be maintained at
|  the GCKS.
|
|        Do we let the initial Cat-1 SA die, and establish a
|  new Cat-1 SA
|        just for the member to send one message (de-register)?
|        This is a lot of negotiations and cycles just for one message.
|
|
|    - Authentication of de-register message:
|
|      Clearly this de-register message has to be
|  source-authentic, otherwise
|      any member can de-register other members.
|
|      This points to the need of the members to have
|  certificates (which
|      they do anyway, in order to register in the first place, both
|      in GSAKMP and GDOI).
|
|      Since we assume that the Application triggered the
|  initial Register
|      message (digitally signed), then it make it makes sense to let
|      the Application decide (and send) the final de-register
|  message (with
|      a digital signature).
|
|
|    - Reliability:
|
|      In SMuG and MSEC we all concluded that reliability of
|  key management
|      messages should not have to be dealt by the
|  key-management-protocol.
|
|      Now, if you insist that the de-register message must be part of
|      the key management protocol, then you also must provide it
|      with reliability.
|
|      Simply saying that "some layer above" will provide it
|  with reliability
|      is really insufficient (circular argument).
|
|      However, it makes sense to say that the Application (or
|  a transport-layer
|      mechanism) will provide/assume reliability.  Which, again, points
|      to appropriateness of the de-register message at the
|  Application layer.
|
|
|  thomas
|  ------
|
|
|
|
|  _______________________________________________
|  msec mailing list
|  [email-masked]
|  http://www.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 16:15:57 -0700

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