1. MIKEY, Revisited Lakshminath Dondeti ldondeti@qualcomm.com Thanks to: Dragan Ignjatic, Ran Canetti and others

2. IETF-66, Montreal, July 2006MSEC WG meeting2 A brief history of MIKEY, and issues  A long time ago MIKEY was standardized via MSEC Efficient 1 RT protocol, using TSs for replay protection  Several modes, PSK, RSA, DH  DHHMAC and RSA-R also became MSEC items MIKEY transport was to be either  UDP, port 2269 (which was dropped before 3830 was published, but used by 3GPP MBMS), OR  SDP ( http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-15.txt ) http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-15.txt  MIKEY is said to be non-deployable None of the modes address Forking, Retargeting, Call Forwarding and Media Clipping No mode negotiation, introducing serious hurdles for deployment Time synchronization requirement is considered another roadblock

3. IETF-66, Montreal, July 2006MSEC WG meeting3 Solution1: use some other protocol  Let’s just find other protocols Several proposals came about  DTLS-based  New protocols What’s common in the new proposals?  Media-path transport  Mode and algorithm negotiation supported  Nonce-based replay protection, DH-based AKE protocols What’s missing?  SRTP policy negotiation  Support for group key management

4. IETF-66, Montreal, July 2006MSEC WG meeting4 Solution2: small fixes to MIKEY  Let’s fix MIKEY! If that’s the goal, what needs to be fixed Need mode negotiation and support for sending credentials  Solution: use MIKEY-DH modes only, and perhaps a 3 rd message to avoid clipping  What about latency?  Signaling path is slower than media path (This is a problem)  What about Time Synchronization?  If there are 3 messages, we can use nonce-based replay protection  This may re-introduce the clipping problem

5. IETF-66, Montreal, July 2006MSEC WG meeting5 Solution 3: MIKEYv2, a re- design(1/3)  Media-path transport seems like an obvious first step See the SIP-path vs. Media-path transport RTPsec presentation  Some choices to consider... Is DH necessary?  Seems like it, if PFS is at least an optional feature to support Should GSA establishment be supported?  Yes, better start with that rather than add it later Should we re-use MIKEY payloads?  Yes, makes sense; they support SRTP policy negotiation  Need an authenticated key management (AKM) protocol using nonces for replay protection

6. IETF-66, Montreal, July 2006MSEC WG meeting6 Solution 3: MIKEYv2, a re- design(2/3)  More choices to consider … Should we use SIGMA as the basis?  Makes perfect sense  Turns out some of these are at odds with each other While we want to re-use MIKEY payloads, the HDR field is not sufficient for a multi-RT AKM protocol  The CSB ID in the MIKEY HDR field is not sufficient to demultiplex multiple simultaneous MIKEY protocol runs  Perhaps we might use the IKEv2 HDR instead? Or introduce some of the fields into the MIKEY HDR.  At any rate, MIKEY HDR field needs to change.

7. IETF-66, Montreal, July 2006MSEC WG meeting7 Solution 3: MIKEYv2, a re- design(3/3)  More design choices: Is ID protection necessary?  What kind?  Active/Passive Initiator/Responder ID protection are the choices  SIGMA can provide this Who starts the KM protocol?  Answerer, it seems like  The answerer does have an idea of who the offerer is  No Active Responder ID protection possible

8. IETF-66, Montreal, July 2006MSEC WG meeting8 Summary of MIKEYv2  An AKM protocol that Re-uses MIKEY as much as possible And SIGMA and IKEv2 where necessary Supports algorithm negotiation Solves forking, clipping etc., Supports GKM Runs in the media-path  Does this seem like a meaningful protocol to develop for SRTP keying? Why/why not?