Last Modified: 2005-03-02
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-62, Minneapolis, MN (Nov 8, 2004) ------------------------------------------------------- Meeting at Thursday 10 March, 9:30-10:30AM Minute takers: Marshall Eubanks & Brian Weis Welcome & Draft Updates - Brian Weis ------------------------------------ o No changes to agenda o Review of WG drafts Two drafts are in the RFC Editor Queue: - draft-ietf-msec-gkmarch-08 - draft-ietf-msec-tesla-intro-04 Three drafts are currently in IESG Evaluation - draft-ietf-msec-gsakmp-sec-07 - draft-ietf-msec-ipsec-signatures-04 - draft-ietf-msec-mikey-dhhmac-09 The WG chairs will be forwarding three drafts to the Security ADs: - draft-ietf-msec-bootstrapping-tesla-00 - draft-ietf-msec-newtype-keyid-01 - draft-ietf-msec-srtp-tesla-03 Th WG chairs will be putting deadlines on two drafts in hopes that they will move forward: - draft-ietf-msec-tesla-spec-00 - draft-ietf-msec-gdoiv2-01 Several other drafts need status updates from the authors. - draft-ietf-msec-policy-token-sec-02 - draft-ietf-msec-tokenspec-sec-00 - draft-ietf-msec-gspt-02 2401bis and multicast issues - Russ Housley ------------------------------------------- o The IPSEC and MSEC WGs coordinated to ensure that ESPv3 and AHv3 could accommodate multicast. However, RFC2401 specifies the framework for IPsec. It also has some issues with multicast. As part of the 2401bis document review they found that 2401bis does not support all multicast security associations. o Rather than hold up the 2401bis document, Russ is asking the MSEC WG to publish a new document to support multicast in the 2401bis framework. o Specific issues include: - The Multicast Security Architecture (RFC 3740) needs to be specifically applied to IPsec. - The Group SPD (GSPD) described in RFC 3740 needs to be described specifically for IPsec. For example, the outbound traffic directed to a multicast address will not have a companion inbound SA with the multicast address as the source. - The Security Association Database (SAD). Currently, only manually configured multicast SAs are supported. o Russ indicated that this work should begin once the 2401bis document has been approved for publication by the IESG. This should happen soon. Additional mode of key distribution for MIKEY - Francois Audet -------------------------------------------------------------- o draft-ignjatic-msec-mikey-rsa-r-00 o The current MIKEY Public key mode requires initiator to have the responder's Public key before sending the first message. Yet very often one does not have the receiver's public key in advance, especially for p2p communications such as SIP. Without the certificate of the responder, the initiator cannot use the MIKEY public key mode. o There are cases where the initiator is willing to do SRTP even he does not know exactly who the responder will be: for example, in a corporate telephony environment. Furthermore, SIP calls may be made to a group of devices (e.g., group aliases, SIP forking), and the initiator cannot be sure in advance which one will answer. o The authors propose a new MIKEY mode, where the responder sends its public key in the reply message, along with its signature. o This mode is useful for unicast, and also for multicast where a client contacts a key server, but doesn't already have the key server's public key. However, the multicast case needs further description in the document. o The authors ask that this be accepted as a WG document. This request will be taken to the WG mailing list. Richard Graveman: There are two cases this is useful: 1) when you don't have the responders public key, or 2) when you don't know who is on the other end. The first case makes sense, but can you give guidance on when this mode is appropriate in the second case? Francois: Its the initiators choice on when to use it. The key question for the initiator is, "Am I trying to connect to a particular person, or do I just want to use encryption?". Steffen Fries: This is a really helpful approach, but the draft needs mode description on the multicast case, when you can't use DH. Francois: Lakshminath will be adding a multicast case to the document. It is clear that this is what got him excited about this approach. MIKEY using elliptic-curve methods - Andrew Milne ------------------------------------------------- o draft-ietf-msecmikey-ecc-00 (not yet submitted) o Elliptic curve (ECC) is useful in MIKEY because you can use a shorter key to achieve the same security. For example, if you went equivalent security as a 356 bit symmetric key you would need to use 15,360 bit DH/RSA but just a 571 bit ECC public key. o There are four primitives described in this draft: - ECDSA (Digital Signature Algorithm). - ECDH (Elliptic Diffie-Hellman). - ECIES (Integrated Encryption Scheme). This is Equivalent to public key, and is a good one-pass method. - ECMQV. This is a drop-in replacement for signed Diffie-Hellman, although is a little awkward for MIKEY. o ECMQV has three versions: one-pass, two-pass, and three-pass. At least the two-pass and three-pass variants would require quite a bit of change to MIKEY. Russ Housley: MQV is really cool, but not a simple plug-n-play replacement, so the WG needs to decide if it wants to do the work to modularize MIKEY or not to accommodate this. Russ Housley: Can you explain the IPR situation? Andrew: Certicom has IPR in this area. It would be difficult to implement much in this draft without Certicom, although it depends a bit on which curve you are doing. ECMQV is covered by the US Government Elliptic Curve Licensing Agreement. [Editor's Note: See the SAAG minutes for IETF61 for a discussion of this licensing agreement.] Richard Graveman: Regarding IPR, are there any documents that describe the algorithms publicly? Andrew: There are IEEE and ANSI documents for which you must pay. I did put a description of MQV in the document (which did not make the deadline). Update on DHHMAC draft - Steffen Fries -------------------------------------- o draft-ietf-msec-mikey-dhhmac-09.txt o There have been two drafts with minor changes since IETF61, and the AD Review has been completed. o A third-party IPR disclosure entry has been submitted to IETF, see https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=539 Bootstrapping TESLA draft - Steffen Fries ------------------------------------------ o draft-ietf-msec-bootstrapping-tesla-00.txt o At IETF61 there are a lot of discussion regarding whether this should be its own document, or merged with the srtp-tesla Internet-Draft. After a discussion on the mailing list it was decided to keep it separate. o This draft has a clarification about time synchronization, that it can be done either by using NTP, or by piggybacking this information in MIKEY. o The WG last call for the document ended on March 4th; no further technical comments were made. |