Subject: Re: [MSEC] re-Charter of MSEC and milestones

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Jul 2003 16:14:46 -0400

Thomas and Ran,

What about the Policy Token I-D (draft-ietf-msec-tokenspec-sec-00.txt) 
in the charter timeline?   It appears that GSAKMP is closely tied in 
with that spec, so I guess it is better to have them go to last call 
simultaneously.

regards,
Lakshminath

Thomas Hardjono wrote:
> 
> [ps. Some housekeeping details for MSEC WG. (TH)]
> 
> 
> Folks,
> 
> Below is the re-Charter of MSEC (which was discussed at the last IETF) 
> and the revised milestones.
> 
> The main text of the re-Charter is unmodified (as from the last IETF) 
> and has been approved by the ADs.
> 
> However, some of items on the milestone have been pushed further out, in 
> order to provide authors with ample time.  We are still waiting AD 
> approval for these few modifications to the milestone, but they should 
> be ok.
> 
> Hint to authors: just because a draft's milestone has been pushed 
> further out, it does not mean that it can/should not be completed 
> earlier (and thus go to Last Call earlier).
> 
> cheers,
> 
> thomas
> ------
> 
> --------------------------------------------------------------------
> MSEC CHARTER
> 
> The purpose of the MSEC WG is to standardize protocols for securing 
> group communication over internets, and in particular over the global 
> Internet. Initial efforts will focus on scalable solutions for groups 
> with a single source and a very large number of recipients. Additional 
> emphasis will be put on groups where the data is transmitted via 
> IP-layer multicast routing protocols (with or without guaranteed 
> reliability). The developed standard will assume that each group has a 
> single trusted entity (the Group Controller) that sets the security 
> policy and controls the group membership. The standard will strive to 
> provide at least the following basic security guarantees:
> 
> + Only legitimate group members will have access to current group 
> communication. This includes groups with highly dynamic membership.
> 
> + Legitimate group members will be able to authenticate the source and 
> contents of the group communication. This includes cases where group 
> members do not trust each other.
> 
> An additional goal of the standard will be to protect against 
> denial-of-service attacks, whenever possible.
> 
> Due to the large number of one-to-many multicast applications and the 
> sometimes conflicting requirements these applications exhibit, it is 
> believed that a single protocol will be unable to meet the requirements 
> of all applications. Therefore, the WG will first specify a general 
> Reference Framework that includes a number of functional building 
> blocks. Each such building block will be instantiated by one or more 
> protocols that will be interchangable. The Reference Framework will not 
> only describe one-to-many multicast, but also many-to-many multicast.
> 
> 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 will generate at least the following documents, which could be 
> considered as base documents:
> 
> 1. An RFC describing the security requirements of multicast security and 
> an RFC describing the MSEC Architecture.
> 
> 2. An RFC describing the Group Key Management Architecture and an RFC 
> describing Group Policy Management Architecture in MSEC.
> 
> 3. Several RFCs describing specifications for protocols that implement 
> source authentication, group key management and group policy management.
> 
> As multicast security covers a broad range of issues, and therefore 
> touches other Working Groups in the IETF, the MSEC WG will work closely 
> with other security-related Working Groups (e.g. IPsec, IPSP), as well 
> as other Working Groups which maybe considered a "consumer" of the 
> technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may 
> have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA).
> 
> With this in mind, the MSEC WG is open to receiving new work items, 
> whenever it is considered appropriate to be homed in the MSEC WG.  Such 
> drafts will be matured in conjunction with the MSEC base documents.
> 
> 
> GOALS AND MILESTONES
> 
> DONE      Working Group Last Call on GDOI Protocol.
> 
> DONE      Working Group Last Call on MIKEY Protocol.
> 
> Sep 03    WG Last Call on Group Key Management Architecture draft.
> 
> Sep 03    WG Last Call on MSEC Architecture draft.
> 
> Sep 03    WG Last Call on DHHMAC for MIKEY.
> 
> Sep 03    WG Last Call on Data Security Architecture draft.
> 
> Sep 03    WG Last Call on GSAKMP protocol.
> 
> Dec 03    WG Last Call on Security Requirements draft.
> 
> Mar 04    WG Last Call on Group Security Policy Architecture
>           draft
> 
> Mar 04    WG Last Call on MESP (Multicast ESP) draft.
> 
> Mar 04    WG Last call on MESP-TESLA draft.
> 
> Jul 04    WG re-charter for other work items (or disband).
> 
> --------------------------------------------------------------------
> 
> 
> 
> 
> 
> _______________________________________________
> 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: canetti <[email-masked]>
Date: Wed, 2 Jul 2003 23:54:42 -0400 (EDT)

Any of the GSAKMP authors care to comment on that?
Would you like to postpone your deadline to be aligned with
the policy token document?

Ran