Last Modified: 2004-09-07
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 |
RFC3740 | I | The Multicast Security Architecture |
RFC3830 | Standard | MIKEY: Multimedia Internet KEYing |
----------------------------------------------------
MSEC WG Minutes, IETF-61, Washington D.C. (Nov 8, 2004) ---------------------------------------------------- Meeting at Monday 8 November, 7:30-9:00PM Welcome - Ran Canetti --------------------- o No changes to agenda o Review of WG drafts - draft-ietf-msec-mikey-dhhmac-05.txt This draft is currently in AD Evaluation. There is third-party IPR claim on the draft. Russ Housley said that he will wait until the IPR claim is understood before reading the draft. - draft-ietf-msec-ipsec-signatures-01.txt This draft is under AD evaluation. Russ has submitted AD comments on the draft. Brian will be producing a new draft answering those comments shortly after the I-D queue re-opens. There was some discussion on whether the minimum (496 bits) is too small, or whether that is OK if only used for an SA with a short lifetime (e.g., 30 minutes). Russ would like the draft to have more guidance on acceptable key sizes. - draft-ietf-msec-gsakmp-sec-05.txt This draft is currently in IETF Last Call. Hugh had a question on what happened to the policy token draft, as it is referenced by the GSAKMP draft. Russ said that the GSAKMP draft should finish Last Call. It just can't proceed any further until the normative policy token document advances to the same level. - draft-ietf-msec-gkmarch-08.txt This draft included text to satisfy some IESG Discuss points. Russ will send the text to the people who brought up the Discusses and hope to get them resolved. - draft-ietf-msec-tesla-intro-03.txt Remarks from IESG are being addressed, and a new draft will be out soon. - draft-ietf-msec-tesla-spec-00.txt A revised I-D is needed. o Other drafts will be discussed in following presentations. General Payload Type in MIKEY - Elizabetta Carrara ------------------------------------------------- o draft-carrara-newtype-keyid-00.txt o The objective of this draft is to define a new type in the general extension payload in MIKEY. This is needed by the multimedia broadcast/multicast service (MBMS) in 3GPP (Rel6). The streaming scenario uses SRTP for media protection and MIKEY for key mgmt. MBMS requires some extensions in order to pass all of MBMS types of keys. o Ran asked what type of document that the authors would like to see, and Elizabetta replied that they would like an Informational RFC. o Ran asked if anyone objected to this work item. No one did. o There was some question as to what the IANA considerations for MIKEY said was necessary in order to add to its namespaces, and whether an Info. RFC was acceptable. Later inspection showed that the MIKEY RFC does not specify any criteria regarding what type of document is required to update this. MIKEY DH-HMAC - Steffen Fries ----------------------------- o draft-ietf-msec-mikey-dhhmac-05.txt o Steffan described the changes in the latest version of the document. o The next steps include an AD review. Russ asked for clarification on the third-party IPR statement. Steffan replied that it allegedly was sent to the IETF but that it hadn't appeared on the web site yet. It apparently addresses this draft particularly. Bootstrapping TESLA - Steffen Fries ----------------------------------- o draft-fries-msec-bootstrapping-tesla-00.txt o This draft defines a new payload and policy parameters for bootstrapping TESLA in SRTP. There has been some questions on the mailing list about how to synchronize time between the sender and receivers, and Steffan favors using an out-of-band method (e.g., NTP or SNTP). - Mark pointed out that the most straightforward way to synchronize might be using a round-trip time (like a "ping" round-trip). - Steffan pointed out that it depends on which side initiates the MIKEY protocol. The content receiver would need to initiate the protocol. - Ran said that the content receiver would have to use the interactive version of MIKEY. - Steffan said that it still depends on who initiates MIKEY. - Ran said that in the 2 message the media receiver always starts first. - Lakshminath pointed out that is the optional exchange in MIKEY, not either of the two mandatory ones! - Steffan said that in those you need a 3rd message if the media sender is inviting the receiver. o The working group discussed whether or not that the draft should be stand-alone, or whether it should be combined with the TESLA-SRTP draft. It currently is only used by the TESLA-SRTP draft, but if it remains independent it could be used by other key management protocols supporting TESLA (e.g., GSAKMP). This was discussed at greater length in the next presentation. TESLA_in-SRTP update - Elizabetta Carrara ------------------------------------------ o draft-ietf-msec-srtp-tesla-02.txt o Elizabetta discussed the changes that went into this draft. - Ran asked if is the TESLA information in Steffan's draft consistent with this draft? - Steffan replied that there were some differences. o Ran asked that the working group consider whether these should be one draft or two. - Mark said that the SRTP-TESLA draft should describe both the TESLA signaling and data parameters. - Mark had a concern that there weren't any implementations of the TESLA work, which is key to getting good drafts. We ought to have 2 implementations. o A vote was taken on whether the drafts should be merged. Four voted "for", and two against. The two against were the authors of the drafts, which led to more discussion. - Steffan said he'd like to keep them separate in case another protocol wanted to use the draft to bootstrap TESLA. - Brian pointed out that the draft had packet formats specific for TESLA, which might not work with other protocols. - Hugh mentioned that if you have a mixed group with different key management mechanisms both bootstrapping TESLA (e.g., GSAKMP, MIKEY) how else are they going to make sure the TESLA-SRTP policy works correctly? By marrying the two draft you are making this harder. - Mark summarized Hugh by saying that there could be an interworking problem in the different protocols if they define the policy independently. - Brian said that we didn't make it an objective to make the key management protocols interoperate up 'til now. - Lakshminath asked if the description can go in the TESLA docs? - Ran said that the TESLA introduction draft is informational, so that's the wrong place. We need a standards track document. - Mark asked how about if we create a new MIKEY draft based on the RFC to add the TESLA bootstrapping parameters, since that's where they should have been in the first place? Then the MIKEY draft would be cycled to proposed standard. - Russ gave some things to think about regarding going to proposed std: to advance it it has to have been stable for 6 months. So if you go this route, do the changes earlier so that the two interoperating implementations can be stable for 6 months. - Lakshminath said lots of people like to see a stable RFC before they implement it! That might be a worry to current MIKEY implementers. This decision should be taken to the list. Update on GDOIv2/GKDP - Lakshminath Dondeti ------------------------------------------- o draft-ietf-msec-gdoiv2-01 o This draft has a new name: Group Key Distribution Protocol. This is the result of comments against -00 which said that we might want to actually make a GDOIv2 someday based on RFC 3547. o This draft proposes a variant of GDOI using IKEv2 as the authenticated tunnel rather than IKEv1. There are few updates from -00 time. Lakshminath has a co-author, and is looking for more help. o Look for more updates on the mailing list. Flat Multicast Key Exchange - Emanneule Jones --------------------------------------------- o draft-duquer-fmke-01.txt o Emanneule Jones presented on behalf of authors, who were not able to attend. o The protocol is derived from GDOI, and provides an adapted solution for wireless links. IP over satellite is considered, and possibly also WiFi and WIMAX. o The -01 draft has been changed to be a use a case of GDOI, and underlines the differences between the protocols. - George pointed out that the reliability protocol in FMKE has attributes that resemble the RMT "NORM" protocol. It is an RMT building block that is optimal for this kind of problem. o Two demonstrators have been developed using FMKE. One was part of the IST Satip6 project. The other was a military DVB-RCS application. In both cases FMKE phase 1 and phase 2 ESP were implemented. o The next steps are to minimize the FMKE changes, fold them into GDOI if it is possible and publish a a new version of GDOI. - Brian said that he didn't see why the proposed changes could be added to GDOI rather than creating a new DOI value (as the current draft proposes), but we need to talk about the requirements, and what requirements that GDOI can currently solve. Specific comments should be posted to the list to start a discussion with the authors. - Mark said that GDOI doesn't address reliable multicast, and has no back channel operation. His thought is that GDOI should be able to support these in the base specification. A further proliferation of key mgmt protocols is not a good thing. - Hugh pointed out that Logica is solving this problem using GSAKMP. - Ran suggested that maybe this should be folded into GKDP. o Ran asked if this work in scope? - Brian said yes, that it is addressing the issue with an IP network with interesting characteristics. - Mark said that we should get together the GDOI and DMKE authors to talk about this in the next few weeks. Wrap Up - Ran Canetti --------------------- o Ran pointed out that according to our charter we should be done soon, and asked if there should be new work items? - George said a generic policy token. - Hugh clarified that this is the point of a policy token. - Lakshminath mentioned that we talked about reliable transport of rekey messages two years ago, and said that simple repeated transmission of rekey messages should work. Now that this is coming up again in FMKE, it might be time again in the March meeting to discuss this and how we should do this. - Ran mentioned a policy token for ESP. |