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

From: Ran Canetti <[email-masked]>
Date: Sun, 8 Jul 2001 15:00:30 -0400

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

---

From: Mark Baugher <[email-masked]>
Date: Sun, 08 Jul 2001 13:52:48 -0700

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