Multimedia Internet KEYing (MIKEY) [RFC 3830] as the key management protocol

In 2003, Johan Bilien, Key Agreement for Secure Voice over IP, M.Sc. Thesis [Bilien 2003] extends an earlier thesis - Runs on a laptop or iPAQ under linux

Secure Call Setup [Bilien 2004]

Total delay (in ms)	Calling Delay	Answering Delay
No security	19.5	9.5
MIKEY, shared key	20.9	10.5
MIKEY, Diffie-Hellman	52.5 (UDP) 58.9 (TCP)	47.6 (UDP) 48.9 (TCP)

Total delay (in ms)

Calling Delay

Answering Delay

No security

19.5

9.5

MIKEY, shared key

20.9

10.5

MIKEY, Diffie-Hellman

52.5 (UDP)

58.9 (TCP)

47.6 (UDP)

48.9 (TCP)

name-servers (BIND 8.2 on Linux 2.4, 500 MHz Pentium 3 laptops)
root name-server ns.lab manages the delegation of minisip.com and ssvl.kth.se to their respective name server
two routers (1.1 GHz Celeron desktops) perform static routing, and each router also runs a SIP server, SIP Express Router (SER v0.8.11))
Alice and Bob use minisip, running on 1.4 GHz Pentium 4 laptops,running Linux 2.4

In 2005, Joachim Orrblad in his thesis, “Alternatives to MIKEY/SRTP to secure VoIP” [Orrblad 2005], examines the use of MIKEY together with IPsec.

Slide Notes

Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, “MIKEY: Multimedia Internet KEYing”, IETF RFC 3830, August 2004< http://www.ietf.org/rfc/rfc3830.txt Links to an external site.

Johan Bilien, Key Agreement for Secure Voice over IP, M.Sc. Thesis, KTH Royal Institute of Technology (KTH), Dept. of Microelectronics and Information Technology, Stockholm, Sweden, Dec. 2003. https://urn.kb.se/resolve?urn=urn%3Anbn%3Ase%3Akth%3Adiva-93069 Links to an external site.

Johan Bilien, Erik Eliasson, and Jon-Olov Vatn, “Call establishment Delay for secure VoIP”, WiOpt’04: Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, University of Cambridge,UK, 24-26 March, 2004

Joachim Orrblad, “Alternatives to MIKEY/SRTP to secure VoIP”, Master of Science Thesis, KTH, Microelectronics and Information Technology, Telecommunication System Laboratory, Stockholm/Kista, March 2005

Transcript

[slide364] So that means I can send my media traffic with encryption, protection against replay, and authentication. What about my SIP? And what do I do about exchanging the keys? Well, she looked... This is an experiment by Johan Bilien in his thesis, where he looks at MIKEY to do the key exchange. And he said, well, if I have no security, the calling delay and answering delay are about 19.5 and 9.5 milliseconds. If I add MIKEY with a shared key, it only increases it very slightly, about one millisecond more. It's nothing. It's not even another ring of the phone. And even if I doMIKEY with full Diffie-Hellman, it's less than two packet times, roughly, under 50 milliseconds. So again, you simply wouldn't notice it. And this was already in 2003. So I would posit today that if you're not using MIKEY plus SRTP, you're not taking good care of your communications. And Joachim Orrblad said, Nat, I don't like this approach. What we should really do is combine MIKEY together with IPSEC. And so he did a very interesting study of that, saying, well, why would you want to combine this with MIKEY with IPSEC rather than MIKEY with SRTP? Well, he thought maybe there would be a speed advantage, because I can already do it down in the IPSEC layer. I don't have to have the applications have to know about SRTP. So I can use unmodified VoIP applications. To support SRTP, I need to have an application that actually understands SRTP. But in both cases, he said, you want to use MIKEY, because you need to exchange the keys. What's the big problem with IPSEC? Think about it from the client's point of view. The encryption is happening down at the IP layer. That means my application has no idea whether there's encryption happening or not. It has no way of knowing. Whereas if I'm using SRTP, my application has to know and does know, am I encrypting and protecting my media stream or not? So I actually think the earlier was a better approach.