1 / 8

MIKEY, Revisited

MIKEY, Revisited. Lakshminath Dondeti ldondeti@qualcomm.com Thanks to: Dragan Ignjatic, Ran Canetti and others. 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

xanthus-fox
Download Presentation

MIKEY, Revisited

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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) • 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 MSEC WG meeting

  3. 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 MSEC WG meeting

  4. 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 3rd 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 MSEC WG meeting

  5. 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 MSEC WG meeting

  6. 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. MSEC WG meeting

  7. 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 MSEC WG meeting

  8. 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? MSEC WG meeting

More Related