Last Modified: 2003-10-01
+ 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.
| Done | Working Group Last Call on GDOI Protocol | |
| Done | Working Group Last Call on MIKEY Protocol | |
| Done | WG Last Call on MSEC Architecture draft | |
| Done | WG Last Call on Group Key Management Architecture | |
| Done | WG Last Call on DHHMAC for MIKEY | |
| Dec 03 | WG Last Call on MSEC Security Requirements draft | |
| Dec 03 | WG Last Call on MSEC Policy Token | |
| Dec 03 | WG Last Call on GSAKMP | |
| Dec 03 | Last Call on GSAKMP-Token | |
| Dec 03 | WG Last Call on IP Multicast issues with IPsec | |
| Mar 04 | WG Last call on TESLA-Intro draft | |
| Mar 04 | WG Last Call on MESP Framework (Data Security Architecture) draft | |
| Mar 04 | WG Last call on TESLA-Spec draft | |
| Jul 04 | WG re-charter for other work items (or disband) |
| RFC | Status | Title |
|---|---|---|
| RFC3547 | PS | The Group Domain of Interpretation |
---------------------------------------------------- MSEC WG Minutes, IETF-58, Minneapolis (Nov 10, 2003) ---------------------------------------------------- Meeting at Monday 10 November, 9:00am-11:30am Welcome - Thomas Hardjono ------------------------- o No changes to agenda o Review of WG status: I-D Milestones since last IETF foil - www.securemulticast.org/msec-drafts.htm gives the draft status - Ran: mesp features have been incorporated into IPsec ESPbis - Thomas: Multicast issues draft could go to informational notably the "IPsec issues draft" - Russ: If ESPbis has incorporated everything then should drop this; the consensus is to drop it - No status on secure feedback draft. - Ran: have nothing on how key management works with application layer data protection - Mark: Hard to do this without having a particular application data security protocol in the pipeline but there is some work underway on multicast transport-layer security - Ran: We should define this in anticipation of an application-security protocol - Andrea: GSAKMP is supporting an app protocol that is not an IETF standard; Ran thought that the API and object definition would be of interest - Brian: Is this specifically an API? Ran: Yes. Brian: not sure we need to do an API in the MSEC WG. The thing of interest is the objects and bindings in the protocol for doing this. - Thomas: We need to discuss policy token; we'll do this after Andrea's presentation MIKEY update - Elisabetta ------------------------- o IESG evaluation reviewed (see foilset) - Brian: Is a new PRF RFC required or is this is an extension? Elisabetta said that this was an extension mechanism. - Russ: some means are needed to signal the use of a new PRF - General discussion on the need to decouple MIKEY from the mmusic key-mgt. - Russ recommends to not reference the key-mgt document from MIKEY o Status is that a revised I-D is needed for IESG last call GKMARCH update - Ran (see foils) -------------------- o There are two outstanding issues from WG Last Call, one being peer controllers - George: From receiver, what's important is how the controller is authenticated. Will next draft allow re-key from peers? - Brian: It seems important to allow for this. o We will incorporate needed changes and resubmit to WG last call GSAKMP update - Andrea (see foils) ---------------------- o Changes from last I-D and new additions presented - Ran: are cookies still include in request to join? - Andrea: yes o Draft 04 is out is out and 05 will follow for possible last call - Thomas: Policy token is now broken into two pieces with a generic piece. Would GDOI use them? - Brian: Yes, GDOI could use the policy token o Ran: We are going to be asked about having two separate group key management protocols when GSAKMP goes to the IESG last call in the future. Do we need two? - Mark: historically the difference was between the ISAKMP header that GDOI used and GSAKMP did not. Now there are a lot of different functions in today's GSAKMP. - Brian: GSAKMP also is closely tied to the policy token - Thomas: There is an important application for GSAKMP that is distinct from GDOI just as there was a need for GDOI to leverage the IKE installed base. We need to move GSAKMP forward to WG Last Call a.s.a.p. given that MSEC Charter ends in July 2004. - George: There is something to be said for parallel development of the two protocols; could focus on rekey message as a unifying message, e.g. GDOI uses a great variety of different authorization methods and these distinctions are a concern for the registration protocol and not the rekey protocol - Thomas: When will GSAKMP be ready for last call? How about January or February. - Andrea thought that was reasonable DHHMAC update - Steffen Fries presenting on behalf of Martin (see foils) ------------- o Changes from last I-D o Version 05 will be done by xmas and this is recommended as a last call document - Ran: is there a constituency for this? - Mark: This aligns MIKEY with H.235? Steffen said 'yes' - Betta: Is this needed for H.323? Steffen said 'yes' - Thomas: Is there opposition to moving this forward? (No one in audience opposses). Lets move it forward. - Mark: The motivation would be to align this IETF protocol (MIKEY) with H.235 (would like to do the same with SRTP as well). - Ran: Should take to WG last call? - Thomas: We can do this with draft 05 is submitted. MSEC & AAA - George (see foils) ---------- o Status given and motivation for including AAA/Diameter in MSEC focus. o GDOI could leverage ISAKMP/IKE AAA work but GDOI does not separate KS from GC functions; - Mark: What is the distinction? - George: GC does registration but does not have the key for the group. - Mark: This distinction is not generally well-defined in msec. - George: This was discussed in the MSEC architecture. - Brian: KS could be closest to member but the GC would do registration. - Mark: In general, this problem is difficult and not yet solved in security systems, viz. X.509 PKI across domains. - George: Large-scale multicast groups are likely to be multi-realm and we will need to solve this in MSEC. - Andrea: It is unlikely to be able to separate these functions since there is always a potential collusion problem. o GSAKMP uses the Diameter "push" model as opposed to the GDOI "pull" model. o Have not yet decided how to introduce this to msec. - Thomas: Can't this be in the generic policy token I-D? - George: It will at least influence the design of the generic policy token and could be completely defined there Wrap Up ------- o Korea IETF in Mar 2004: Thomas took a show of hands and found ~9 persons were planning to attend. o Ran might attend so there may be an msec meeting at IETF 59. o Discuss again in mailing-list in early 2004. ---------------------------------------- -------------------- |