MIKEY, Revisited

1
MIKEY, Revisited

• Lakshminath Dondeti
• ldondeti_at_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-iet
  f-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
Solution1 use some other protocol

• Lets just find other protocols
• Several proposals came about
• DTLS-based
• New protocols
• Whats common in the new proposals?
• Media-path transport
• Mode and algorithm negotiation supported
• Nonce-based replay protection, DH-based AKE
  protocols
• Whats missing?
• SRTP policy negotiation
• Support for group key management

4
Solution2 small fixes to MIKEY

• Lets fix MIKEY! If thats 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

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

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.

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

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?