Subject: [MSEC] new charter of MSEC

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Apr 2003 16:39:23 -0500

Ran and Thomas,

I see that there is no timeline or I-D corresponding to the new charter 
item, i.e., distributed architectures.  Would text on this topic from 
the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) I-Ds be a 
starting point for this?

Thanks.

regards,
Lakshminath

"In addition, as a secondary goal the MSEC WG will also focus on
distributed architectures for group key management and group policy
management, where for scalability purposes multiple trusted entities (such
as Key Distributors) are deployed in a distributed fashion. For this
purpose, the Reference Framework will not only describe one-to-many
multicast, but also many-to-many multicast."

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

---

From: Hugh Harney <[email-masked]>
Date: Thu, 3 Apr 2003 12:26:11 -0500

Lakshminath,

Well GSAKMP does support distributed architectures.

The GKMP architecture RFC discusses this also RFC 2093

Hugh

On Tuesday, Apr 1, 2003, at 16:39 US/Eastern, Lakshminath Dondeti wrote:

> Ran and Thomas,
>
> I see that there is no timeline or I-D corresponding to the new 
> charter item, i.e., distributed architectures.  Would text on this 
> topic from the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) 
> I-Ds be a starting point for this?
>
> Thanks.
>
> regards,
> Lakshminath
>
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 03 Apr 2003 15:25:06 -0500

I think the intention was to open-up the working group to ideas/protocols 
regarding how to manage multiple GCKSs.

I think the Policy-Token work from GSAKMP is definitely a starting 
point.  Perhaps a reasonable target would be to have a separate draft that 
would provide applicability of the token (or some authorization method) for 
all of the key management protocols.

Also, though the token provides authorization, there is still the open 
questions of how one GCKS communicates securely with other GCKSs.  For 
example, do we use point-to-point or a separate group (e.g. like the 
All-KDs-group) for GCKSs only.  Perhaps this maybe a protocol-specific 
question.

I think there is a lot within GSAKMP that can be "unearthed", since there 
has been a lot of thinking behind GSAKMP that hasn't made it into the text 
of the GSAKMP-drafts.

thomas
------

At 4/1/2003||04:39 PM, Lakshminath Dondeti wrote:
>item, i.e., distributed architectures.  Would text on this topic from the 
>GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) I-Ds be a starting 
>point for this?
>
>Thanks.
>
>regards,
>Lakshminath
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 03 Apr 2003 15:47:35 -0500

I am still trying to put GSAKMP's policy token and the subordinate GCKS 
functionalities in context with respect to the other protocols, viz., 
GDOI and MIKEY.  As Hugh noted, the policy token can be used by the 
other protocols.

How about the subordinate GCKS functionality?  What are the dependencies 
in making that to work in GDOI, say?  If we can extract those pieces 
into a document, that would be a great starting point for some of the 
new charter items (the many-to-many piece still remains).

If that can be done, it is conceivable to write a GDOIbis (or call it 
GDOI-GSAKMP or GKDP or whatever) spec, that is lightweight (say, based 
on IKEv2), supports (optional?) policy token, and optional distributed 
operation.  While that may be a long way away, would we still need both 
GSAKMP and GDOI then?

regards,
Lakshminath

PS:  This may be a replay of some old discussions, but this time around 
we will include a summary of the discussion in the GKMarch I-D.

Thomas Hardjono wrote:
> 
> I think the intention was to open-up the working group to 
> ideas/protocols regarding how to manage multiple GCKSs.
> 
> point.  Perhaps a reasonable target would be to have a separate draft 
> that would provide applicability of the token (or some authorization 
> method) for all of the key management protocols.
> 
> I think there is a lot within GSAKMP that can be "unearthed", since 
> there has been a lot of thinking behind GSAKMP that hasn't made it into 
> the text of the GSAKMP-drafts.
> 
> thomas
> ------
> 
> 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 03 Apr 2003 16:06:05 -0500

> ideas/protocols regarding how to manage multiple GCKSs.

Along these lines, would it be fair to separate the following two models 
of multiple GCKSs in addressing this topic;

a) multiple GCKSs for scalability and availability of the GCKS services

b) hierarchical subgrouping and designation of a root GCKS and different 
levels of subordinated GCKSs.

The first probably is simpler compared to the second model.

regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Thu, 03 Apr 2003 14:59:40 -0800

At 03:47 PM 4/3/2003 -0500, Lakshminath Dondeti wrote:
>functionalities in context with respect to the other protocols, viz., GDOI 
>and MIKEY.  As Hugh noted, the policy token can be used by the other protocols.
>
>in making that to work in GDOI, say?  If we can extract those pieces into 
>a document, that would be a great starting point for some of the new 
>charter items (the many-to-many piece still remains).
>
>GDOI-GSAKMP or GKDP or whatever) spec, that is lightweight (say, based on 
>IKEv2), supports (optional?) policy token, and optional distributed 

I expect both will be around.  I think that we will want a GDOIbis that is 
optimized to use IKEv2 child SA functionality.  We can consider distributed 
GDOI GCKS mechanisms at that time as well.

cheers, Mark

>regards,
>Lakshminath
>
>PS:  This may be a replay of some old discussions, but this time around we 
>will include a summary of the discussion in the GKMarch I-D.
>
>Thomas Hardjono wrote:
>>has been a lot of thinking behind GSAKMP that hasn't made it into the 
>>text of the GSAKMP-drafts.
>>thomas
>>------
>>