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

From: Ran Canetti <[email-masked]>
Date: Fri, 29 Jun 2001 11:26:49 -0400

Thomas,

I agree with you that in most cases de-registration is not necessary,
since a member joins for a predetermined amount of time. But there is
certainly an added value to the ability to not have to keep paying for
each additional minute/round/episode/whatever - but rather decide to leave
when you want. The question is whether we want to totally exclude the
possibility of doing this using msec?

Note that the de-registration protocol will be optional. we may also
make it optional to implement. so the complexity hit on systems that do not
support it will be minimal. 

In any case, as Andrea and Sandro said, in case that we decide that
de-registration is necessary, it definitely should be handled by msec.
(ie, the application will make a de-registration request which msec will
carry out.)

Regarding the "how", this indeed has to be dealt with. I tend to think
that setting up a new "de-registration SA" is the better/more flexible
way to go (in spite of the added overhead) but I'm open to arguments...
user authentiation and non-repudiation are indeed important concerns here.

Ran

> From [email-masked] Fri Jun 29 08:46:25 2001
> 
> 
> 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: Brian Weis <[email-masked]>
Date: Fri, 29 Jun 2001 10:46:52 -0700

Hi Ran,

> possibility of doing this using msec?

As you've pointed out, a de-registration protocol may make sense in some
cases, but it does seem to be a limited set of cases (i.e., as Thomas
pointed out, not in the current multicast uage models). Rather than
specifying it now, the arch. doc could mention it as a possible protocol
but not leave the specification of it until a later work. 

> (ie, the application will make a de-registration request which msec will

As Sando pointed out, there is an issue with pruning LKH trees. But this
is an issue that should be addressed (in some forum, not necessarily the
arch. document) regardless of whether there is a de-registration
protocol since the GCKS can't be guaranteed to know when members leave
the group (or simply stop listening without leaving the group). 

> user authentiation and non-repudiation are indeed important concerns here.

I'm concerned about MSEC biting off yet another protocol at this point
in time -- we've got a number of specifications to resolve as it is. As
you point out, there are non-trivial concern on how to specify the
de-registration protocol.

Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

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

Ran,

Both Laksminath and myself thought of this problem some time ago.
We can introduce a De-registration-KEK that is delivered initially
in the Registration/Initialization stage.  The unique KEK is then
used to hash (or encrypt) the Deregister-message.  Since only the
GCKS and the member know that Deregister-KEK, then the GCKS can
be assured of its source-authenticity.

The issue is when there is 100 members sharing a symmetric KEK key,
it brings about the Many-to-1 SA management problem.

That is, the GCKS must know from which member the Deregister-command came.
It can hold 100 SAs specially for Deregistrations, or it can maintain
just one (1) SA for the whole 100 members.

If we want to use digital-signatures, then perhaps its better
to do it at the Apps layer.

As Brian mentions, we are still coming to terms
with the Registration/Initialization protocol and the Key-update protocol.
So introducing another protocol may just confuses things.

Better to crawl first.

thomas
------