---------------------------------------------------- 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. ------------------------------------------------------------------------------