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

From: Ran Canetti <[email-masked]>
Date: Wed, 11 Jul 2001 00:30:09 -0400

Mark, 

I think we're very much in agreement here.

I agree that the key management is only part of a secure
multicast protocol, or service. indeed, msec is chartered to standardize
an entire secure multicast protocol suite, of which key management is only a
component.

It is also clear that the key management protocol should not deal with
membership management. There should be different programs/modules that deal
with that (including an MMD as Thomas suggested, etc).  Nonetheless, the KDC
side of the key management protocol should be able to talk with the
membership management module.

My point was/is that since the membership management module is part of 
the secure multicast service, msec should provide a standardized way to
carry out the communication between the membership management module 
and a member. This my or may not go through the key management protocol, but
it should be taken care of. (As usual, if people want to ignore parts of 
the standard that's ok. But the standard should provide a complete service.)

My feeling is that it may often be convenient to "piggyback" the
communication between the member and the MMM (membership management module) 
on the member-KDC communication (and have the KDC forward the necessary info
to the MMM). But this is only an option, as long as the entire service is
taken care of.

Ran

> From [email-masked] Sun Jul  8 20:15:32 2001
> 
> Hi Ran
>    I think you are raising an important point.  Key management is only
> one system out of a number of systems that may make up a complete
> "application" for key management.  I would expect, for example, that
> a service may use a web site for announcement, enrollment of
> members, payment of services, and other functions.  The website
> will probably use SSL.  It probably will not be physically located
> with the key management server in any installation of any size.  But
> it may be the locus of authorization decisions that tells the GCKS
> what to do by signing a member's credential, or instructing key
> management to key the member out of the group.
> 
>    I also expect that an organization may run an accounting system
> or a commercial service may run a billing system.  Secure access to
> these systems are also needed.  Like the website, I don't expect
> these systems will be run on the GCKS, be physically co-located
> with the GCKS, or use the same security system as the GCKS.
> But they may be part of the authorization system that tells the
> GCKS what to do.
> 
>     The point here is that the member may get authorized in very
> application-specific ways by interacting with computers other than
> the GCKS, which authenticates the member and asks for authority
> to admit the member according to the rules set by an arbitrarily
> complex external entity.
> 
>    If we want a key management system that is basic enough to
> support 4 routers, 8 colonels, or a million TV receivers, then we will
> not incorporate a lot of authorization logic into key management.
> 
> Mark
> At 03:00 PM 7/8/2001 -0400, Ran Canetti wrote:
> 
> >Mark,
> >
> >The question is whether this "authorization module" is going to have its
> >own, independent secure communication with the members (ie, communication
> >that is "out of band" for msec), or if msec handles all the communication
> >between the GCKS/KDC/group-owner/whatever and the members that is relevant
> >to membership in the secure group.
> >
> >It seems to me that the first option is bad security design:
> >-It overburdens the application. now the application has to deal with another
> >type of secure connection, with its own policy issues, subtleties, etc.
> >(also, where will that be specified/standardized?)
> >-This is a wide open hole that simply asks for all kinds of unexpected
> >security weaknesses which result from bad interactions between the
> >msec protocol and the "out of band" communication with the authorization
> >module. When designing a security protocol You dont do "half a job".
> >You provide a complete, well-defined service.
> >
> >Ran
> >
> >
> > > From [email-masked] Sun Jul  8 14:33:37 2001
> > >
> > > Ran,
> > >
> > > At 12:11 PM 7/6/2001 -0400, Ran Canetti wrote:
> > >
> > > >We may have terminology problems here. the GCKS *is* the group owner.
> > > >It authenticates members when it talks to them, so there is no issue of
> > > >trustworthiness.
> > >
> > > This is not the model of GSAKMP, GDOI, or the GKM architecture.  A
> > > "policy creation authority" may be used in GSKMP (p.13).   A "Group
> > > Owner" authorizes a member to join a GDOI group (3.2).  In section
> > > 3 of GKM architecture, a single group owner is designated as the root 
> > of trust.
> > >
> > > It is true that the GCKS authenticates members.  But some other authority
> > > authorizes them.  You could say that the GCKS is owned and operated
> > > by the group owner, and that is a legitimate model.  It's also true 
> > that the
> > > GCKS or its delegate could be co-resident with a sending member.
> > > But these are special cases of the more general architecture.
> > >
> > > For authorization in the more general case, the GCKS acts on behalf of
> > > a variety of authorization applications just as the member acts on behalf
> > > of a variety of security protocols (viz. Figure 3 in
> > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt).
> > >
> > > Mark
> > >
> >
> >
> >_______________________________________________
> >msec mailing list
> >[email-masked]
> >http://www.pairlist.net/mailman/listinfo/msec
> 
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec
> 

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

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 11 Jul 2001 11:43:02 -0400

Ran, Mark,

At 7/11/2001||12:30 AM, Ran Canetti wrote:

>and a member.

I am suggesting a simple database (similar to the SAD in functionality)
that has a collection of information.  It doesn't have to be
a complete module (as the term "module" implies).

I don't know if we need a standardized way for a member to talk
with the MMD.  The IPsec/IKE RFCs does not even talk about *how*
the SAD is accessed.  Its an implementation issue.

>This my or may not go through the key management protocol, but

Historically, the IETF tries to to make practical and implementable
standards that vendors can implement.  This process has a better
chance of suceeding if the issue being solved is well defined
and does not try to incorporate unncessary componenets/elements.

If vendors later want certain things to be included in the MSEC standards,
I'm sure they will bring up the issue.

We don't want to spend time on parts of MSEC that no one will use,
even if it means sacrificing the perception of a "complete service".

>to the MMM). But this is only an option, as long as the entire service is

Again, I think it is unwise to start talking about communications
between the MMD and the member.  This may de-focus our current
discussion on key management, Rekey-Protocol, and the need of
some membership data within the Rekey-Protocol.

Ran,

I would appreciate if you would not twist the simple MMD
into an MMM (whatever MMM may be).  Lets just look at the concept of
a simple collection of membership information that can be used also
by the Registration Prot., Rekey Prot., and IGMP.
If it is not needed, then we'll forget about it.

Each time I suggest something, you seem to turn it into something else :)

thomas
------