This chapter is from the book Securing VoIP Networks, by Peter Thermos and Ari Takanen. Published Aug 1, 2007 by Addison-Wesley Professional.

Key management is a fundamental part of protecting Internet multimedia applications such as VoIP. At the same time, key management protocols are difficult to design, especially for multimedia applications that require group participation (for example, videoconferencing, broadcasting or multicast audio, video or file transfer). Until recently, various key-exchange mechanisms such as IKE were proven to support asynchronous communications (that is, file transfer) but were not suitable for group or multicast Internet multimedia applications. Therefore, a distinct effort has been initiated within the IETF to establish such capability. The IETF RFC 4046, “MSEC Group Key Management Architecture,” defines an architecture that consists of abstractions and design principles for developing key management protocols. The MSEC architecture defines a set of requirements for developing key management protocols. These requirements discuss the properties and principles that key management protocols should exhibit for scalability, group security policy, associations (encryption key, lifetime, and so on), group membership, rekeying, attack deterrence, and recovery from compromise.

Multimedia communications such as VoIP require key negotiation protocols that can provide robust and extensible capabilities for multicast and unicast communications. For example, protocols such as TLS and IKE do not provide such capabilities. Group key management protocols can be used to protect multicast and unicast communications between users, user groups, and subgroups (through the group security association). In addition, they have to demonstrate resistance to attacks from external and internal sources (that is, impersonations, DoS).

Within the MSEC architecture, a multicast or group security architecture is defined in which key negotiation and key management are components. Negotiation of keying material is one of the most challenging topics for VoIP (and, generally, Internet multimedia applications). Those who want to maintain confidentiality and integrity of their communication need a robust and secure mechanism to reliably exchange cryptographic keys. Primarily, there are two methods of exchanging keying messages:

• Integrated keying, through the session establishment protocol, such as SIP2. This approach requires fewer messages to be exchanged, and thus minimizes associated delays introduced by message exchange.
• Native key exchange through a distinct process. This approach requires more messages to be generated between end points, and thus increases the risk of associated delays introduced by message exchange. Furthermore, a device cannot determine in advance whether the remote end point can support a particular key-exchange mechanism. For example, Bob sends an INVITE to Alice, but Bob doesn't know whether Alicefs device can support MIKEY3 because the initial exchange of messages does not contain any corresponding information. At this point, Bob can't determine whether his call will be encrypted or there is a delay in setting up the encryption unless his phone has the capability to alert him.

Download PDF to continue reading this sample chapter

» posted by ITworld staff

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine