Subject: RE: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd)

From: Euchner Martin <[email-masked]>
Date: Mon, 18 Aug 2003 16:23:36 +0200

Thomas,

I checked the web page entry wrt. DHHMAC draft. 

Please update the URL to the document to point to the -03 version.

The last column says that "WG Last Call Completed.". This is not quite correct, as far as I understand the current process. I believe that this WG LC is still ongoing and will go on until the end of August 2003.

So it would be more accurate to say "currently in WG Last Call".

BTW: It appears that the IESG ID tracker tool does not know about the WG LC state.

https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=MSEC&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=&search_area_acronym=&search_button=SEARCH

(take care of broken URL).

I'm a bit confused that some entries in the table reference not just the current version but also older, sometimes even expired versions of an ID. Isn't this a bit too confusing and not quite inline with the practice of referencing IDs?

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Thomas Hardjono [mailto:[email-masked]] 
Sent:	Thursday, August 14, 2003 7:30 PM
To:	Lakshminath Dondeti; canetti
Cc:	[email-masked]
Subject:	Re: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd)

Following Lakshminath's excellent suggestion, I have modified the page into 
a table with three columns:

(a) The name of the draft
(b) Destination track
(c) Current Status.

Please take a look and verify/correct (ps. bound to be some errors :)
http://www.securemulticast.org/msec-drafts.htm

thomas
------

At 8/12/2003||02:39 PM, Lakshminath Dondeti wrote:
>It would have been more informative if each of the work items had a track 
>tag (informational/experimental/standards) next to it.  Hope you can do 
>that for the charter page on the IETF site.
>
>Thanks,
>Lakshminath
>
>canetti wrote:
>
>>---------- Forwarded message ----------
>>Date: Tue, 12 Aug 2003 09:51:21 -0400
>>From: The IESG <[email-masked]>
>>To: IETF-Announce:  ;
>>Cc: [email-masked], [email-masked]
>>Subject: WG Action: RECHARTER: Multicast Security (msec)
>>
>>The charter of the Multicast Security (msec) working group in the
>>Security Area of the IETF has been updated. For additional
>>information, please contact the Area Directors or the working
>>group Chairs.
>>
>>Multicast Security (msec)
>>-------------------------
>>Current Status: Active Working Group
>>
>>Chairs:
>>
>>Ran Canetti <[email-masked]>
>>Thomas Hardjono <[email-masked]>
>>
>>Security Area Director(s):
>>
>>Russell Housley <[email-masked]>
>>Steven Bellovin <[email-masked]>
>>
>>Mailing Lists:
>>
>>General Discussion: [email-masked]
>>To Subscribe: [email-masked]
>>In Body: subscribe
>>Archive: <http://www.pairlist.net/mailman/listinfo/msec>
>>
>>Description of Working Group:
>>
>>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 interchanable. 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 othersecurity-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
>>
>>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.
>>
>>Mar 04 WG Last Call on GSAKMP-Light protocol.
>>
>>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

_______________________________________________
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: "Hardjono, Thomas" <[email-masked]>
Date: Mon, 18 Aug 2003 10:27:51 -0700

Martin,

Apologies for the typo.  Let me update the page.

Let me also see what to do about the ID tracker.

cheers,

thomas
------

> From: Euchner Martin [mailto:[email-masked]] 
> Sent: Monday, August 18, 2003 7:24 AM
> To: 'Thomas Hardjono'; Lakshminath Dondeti; canetti; Euchner Martin
> Subject: RE: [MSEC] WG Action: RECHARTER: Multicast Security 
> (msec) (fwd)
> 
> 
> Thomas,
> 
> The last column says that "WG Last Call Completed.". This is 
> not quite correct, as far as I understand the current 
> process. I believe that this WG LC is still ongoing and will 
> go on until the end of August 2003.
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=sea
> rch_list&search_job_owner=0&search_group_acronym=MSEC&search_s
> tatus_id=&search_cur_state=&sub_state_id=6&search_filename=&se
> arch_rfcnumber=&search_area_acronym=&search_button=SEARCH
> 
> I'm a bit confused that some entries in the table reference 
> not just the current version but also older, sometimes even 
> expired versions of an ID. Isn't this a bit too confusing and 
> not quite inline with the practice of referencing IDs?
> 
> 
> 
> With kind regards
> 
> Martin Euchner.
> | Hofmannstr. 51                 Intranet: 
> http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/
> Please take a look and verify/correct (ps. bound to be some 
> errors :) http://www.securemulticast.org/msec-drafts.htm
> 
> thomas
> ------
> 
> 
> 
> 
> >>information, please contact the Area Directors or the working group 
> >>Chairs.
> >>
> >>policy and controls the group membership. The standard will 
> strive to 
> >>provide at least the following basic security guarantees:
> >>
> >>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 interchanable. The Reference 
> Framework 
> >>will not only describe one-to-many multicast, but also many-to-many 
> >>multicast.
> >>
> >>1. An RFC describing the security requirements of multicast 
> security 
> >>and an RFC describing the MSEC Architecture.
> >>
> >>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 othersecurity-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).
> >>