Dr. Dobb's Journal November 2001
Because intruders get sadistic pleasure in discovering security holes in cable networks, cable providers are defining rigorous standards before deploying their Internet Protocol (IP) telephony networks. Chief among these efforts is the release of the PacketCable Security Specification (see PKT-SP-SEC-102-001229, http://www.packetcable.com/specs/PKT-SP-SEC-I02-001229.pdf), which is a document that defines the architecture and protocols necessary to secure packet-based telephony networks. In this article, I'll examine the most prevalent threats to a cable IP telephony network, explore how PacketCable security works, and examine whether it withstands the attacks that will be unleashed against it.
Although transporting voice packets over IP enables cable companies to create exciting new applications, it also exposes their networks to a plethora of new attacks including theft of service, interception, and network disruption. "Theft of service" is the politically correct term for stealing telephony features like call waiting or caller ID from a cable company or a Multiple Service Operator (MSO). Since rampant theft of service can devastate the MSO's bottom line, one of PacketCable's primary goals is to minimize its impact. In particular, the specification wants to deter the occurrence of masquerading and falsified identification.
Masquerading refers to techniques, such as modifying firmware, that hackers use to alter devices and gain unauthorized access to MSO's networks. By contrast, falsified identification describes bogus credit-card numbers and invalid addresses that thieves feed into legitimate devices to illegally enter networks.
While theft of service is more glamorous, interception can be equally devastating to MSOs. These attacks come in two types — stream and signal. Stream interception covers techniques such as illegally monitoring a live audio stream or capturing an audio stream and analyzing it offline. Signal interception involves sniffing Media Gateway Control Protocol (MGCP) packets for sensitive information. These packets are intended to give instructions to the device controlling your phone, but if hackers can intercept them, they have access to precious information such as the caller's phone number and name. These types of attacks reduce customer faith in an MSO's ability to protect privacy and, if such attacks become chronic, customers will abandon the service and revenues will plummet.
The last category of attack is network disruption. Most people equate network disruption with Denial of Service (DoS) attacks because DoS attacks have garnered so much publicity (DoS attacks flood networks with bogus packets and prevent legitimate requests from being processed). Although cable networks are vulnerable to DoS attacks, small-scale network disruptions can be even more frustrating for MSOs. For example, someone with a grudge against the cable company could randomly alter MGCP packets destined for other consumers. Since such alterations would seem random, they would be difficult to diagnose and could have a greater impact on customer satisfaction than a DoS attack that inconveniences consumers for a limited period of time.
Although these are key areas of concern for MSOs attempting to deploy IP telephony services, there are myriad other vulnerabilities that recalcitrant intruders could exploit. Fortunately, the authors of the PacketCable Security Specification are realistic. They're aware that it's impossible to completely eliminate security risks, so they concentrate on securing particularly vulnerable network components, thereby reducing the likelihood of intrusion by the average consumer.
To minimize the MSO's exposure to intruders, the specification divides telephony networks into two categories — untrusted and partially trusted. Untrusted entities reside in consumer premises while partially trusted elements exist inside the MSO's secure network. An untrusted device is known as a Multimedia Terminal Adapter (MTA) or Broadband Telephony Interface (BTI).
MTAs and BTIs contain the necessary hardware and software to interface your phone to the telephony servers in the MSO's network. They come in two flavors — embedded and standalone; see Figure 1. Embedded MTAs combine MTA functionality with a cable modem. By contrast, the standalone MTA doesn't have a cable modem. The PacketCable Security Specification concentrates on embedded MTAs because they will be released first and because the separation of cable modem from the MTA creates additional security concerns.
PacketCable labels MTAs untrusted since it doesn't have physical control over the MTAs and can't be assured that they haven't been hacked. Consequently, PacketCable mandates that all communication (both signaling and multimedia streams) must occur over a security protocol that authenticates the MTA and encrypts all subsequent communication. The MTA uses three of these protocols to protect signaling: SNMP Version 3, Kerberos, and Kerberos with PKINIT.
By default, an MTA contains barely enough firmware to boot, but cannot place calls or access network resources. Therefore, once the MTA finishes booting, it searches for a Trivial File Transfer Protocol (TFTP) server that supplies it with the critical IP addresses and configuration data, thus enabling it to navigate MSO networks.
This approach has two significant advantages. First, it lets MSOs upgrade the MTAs by simply modifying configuration files on a centralized server rather than having to manually update each MTA. Second, it minimizes security risks because the MTA doesn't inherently know how to access protected resources.
Before it can download its configuration file from the TFTP server, the MTA must pass a series of security hurdles. First, it seeks out a Dynamic Host Control Protocol (DHCP) server and retrieves the location of the Domain Name Server (DNS) and the domain name of the Provisioning Server (the Provisioning Server is the storehouse of configuration information). It then uses DNS to resolve the domain name of the Provisioning Server into an IP address. However, the Provisioning Server will not supply the MTA with critical information until the MTA authenticates itself.
This authentication process is supervised by a Key Distribution Center (KDC) and is accomplished with the Internet Engineering Task Force's (IETF) Kerberos protocol (more information on Kerberos is available in the IETF's Request for Comments, RFC 1510 document; see http://www.ietf.org/rfc/rfc1510.txt?number=1510). First, the MTA makes an Application Server (AS) request to the KDC to obtain network credentials. If the MTA certificate contained in the request and its MAC address are legitimate, the KDC sends an AS Response containing a Ticket Granting Ticket (TGT) and a session key; see Figure 2.
Once this process is complete, the MTA must obtain an application-specific ticket that lets it securely communicate with the Provisioning Server. Therefore, it issues a Ticket Granting Server (TGS) Request to the KDC. This request contains the name of the Provisioning Server with whom it wishes to communicate and the encrypted TGT and session key it obtained earlier. If the TGS Request is legitimate, the KDC sends a TGS Response to the MTA that contains a Provisioning Server application ticket (see Figure 2).
The MTA then packages this application ticket in an Application (AP) Request and encrypts it with the session key before it sends it to the Provisioning Server. The Provisioning Server retrieves the session key out of the ticket and uses it to decrypt and authenticate the message. If the request is legitimate, the Provisioning Server issues an AP Response with an embedded SNMPv3 security key (Figure 2).
This SNMPv3 security key lets the MTA create a secure SNMP session with the Provisioning Server. Once a secure communication channel is established, the MTA alerts the Provisioning Server about its capabilities via an SNMP INFORM (Figure 2). Attributes sent on the INFORM are the MTA's MAC address, hardware, firmware levels, and device name. The Provisioning Server parses this information, determines the appropriate configuration file for the MTA's capabilities, then issues an SNMP SET command to the MTA that contains the URL of a TFTP server where the configuration file is stored.
Finally, after this arduous ordeal, the MTA can download its configuration file via TFTP. While this approach slightly increases the work required to boot the MTA, it also adds a layer of robustness to the otherwise insecure TFTP transfer process.
A key strength of the PacketCable security architecture is its thorough integration of Kerberos into all aspects of MTA communication. For instance, Kerberos not only is used to secure provisioning data, it is also leveraged to protect Network-Based Call Signaling (NCS) messages.
NCS is a custom version of the MGCP protocol optimized for the cable environment (for more information on MGCP, see my article "The Media Gateway Control Protocol," DDJ, May 2000). Unlike the provisioning boot process, there are strict timing requirements for NCS (for instance, once you pick up a phone, you should hear a dial tone within a few milliseconds). Therefore, conventional Kerberos is supplemented with the PKINIT protocol and Internet Protocol Security (IPSEC) to meet these requirements.
The most timing-sensitive NCS interface is the communication path between the MTA and a Call Management Server (CMS). The CMS's primary role is to authorize the MTA's access to the network and to enable the MTA to call remote parties. Since there are potentially hundreds of thousands of MTAs attached to each CMS or cluster of CMSs, a symmetric MTA authentication protocol could overwhelm the CMS. To explain, symmetric protocols require that a secure channel be established for key exchange before the attributes of the security protocol can be negotiated. By contrast, an asymmetric (or public key) protocol eliminates the processing-intensive step of creating a secure channel to exchange keys because it relies on public/private key pairs to encrypt and decrypt data.
Given the performance differential between asymmetric and symmetric solutions, PacketCable has decided to use the IETF's asymmetric Kerberos Public Key Initial Authentication extension (PKINIT) to secure its CMS/MTA interface. Since PKINIT is an enhancement of the Kerberos protocol, it shares many similarities with the provisioning authentication process. For example, to obtain a certificate to talk to the CMS, the MTA issues an AS Request to a special telephony KDC. The primary difference between the symmetric and asymmetric approaches is the formatting of the AS Request and AS Response.
When using PKINIT, the MTA places asymmetric attributes (such as its public certificate and Diffie-Helman parameters) in the preauthenticator field of the AS Request so the KDC can authenticate the request (Figure 3). If the MTA is authentic, it is granted a CMS ticket and session key in the AS Reply. This CMS ticket is then used by the MTA to establish a high-performance IPSEC session.
IPSEC is a modification to the TCP/IP stack that permits applications to authenticate and/or encrypt datagrams (or data packets). Since the MTA contains negligible intelligence, dozens of messages may need to be exchanged between the MTA and the CMS before a call can be completed. PacketCable selected IPSEC for this interface because it's a widely adopted standard that can be efficiently implemented in software or accelerated in hardware.
To create a secure IPSEC channel, the MTA and the CMS negotiate Security Association (SA) parameters. These parameters include: the lifetime of the SA, authentication and encryption algorithms, and authentication and encryption keys.
Although several cryptographic options can be negotiated when establishing an IPSEC SA, PacketCable relies on the Encapsulating Security Payload (ESP) technique for protecting data. ESP offers confidentiality, verification of data origin, and minimizes the likelihood of replay attacks (replay attacks involve the retransmission of a previously valid packet) by encrypting IP or UDP headers and wrapping them inside an ESP header.
To establish an IPSEC SA with the CMS, the MTA sends the CMS an AP Request that contains the CMS ticket it retrieved from the telephony KDC, as well as the IPSEC parameters needed to create an SA (Figure 3). The CMS responds with IPSEC parameters and the lifetime of the SA. Once the MTA has this information, it can create an SA with the CMS. PacketCable has nicknamed this process "Kerberized IPSEC," since the establishment of an SA is done via a combination of IPSEC and Kerberos. Similarly, the combination of Kerberos and SNMP used during MTA boot-up is labeled "Kerberized SNMP."
While Kerberized IPSEC satisfies the stringent security requirements of the MTA/CMS interface, it is excessive for other CMS interfaces. Since there is a one-to-one relationship between the CMS and other servers on the network backbone (see Figure 4), there is no pressing need for a symmetric protocol. Consequently, the CMS uses IPSEC with Internet Key Exchange (IKE) — a symmetric protocol that excels at negotiating, creating, modifying and deleting SAs for a limited number of sessions. The IKE process is divided into two phases. Phase I authenticates the parties and establishes a secure communication channel. Phase II negotiates SA attributes such as security keys and en- cryption algorithms. Typically, the CMS uses IKE with preshared keys or X.509 certificates to execute the Phase II process. While IKE is used by the CMS to communicate with other servers, it is not used for MTA communication because it doesn't scale as well as the asynchronous Kerberos/PKINIT protocol and it relies heavily on preshared keys or certificates.
Although Kerberized IPSEC and SNMP protect the MSO's network from hacked MTAs, they do not stop third parties from tapping into audio streams. Therefore, to protect multimedia content, PacketCable relies on the Advanced Encryption Standard (AES). PacketCable chose AES because of the stringent processing and timing requirements inherent in multimedia content.
In my article "Security Protocols and Performance" (DDJ, November 2000), I expressed skepticism about PacketCable's approach to securing audio streams. These concerns arose because multimedia data packets must be decompressed within a few milliseconds of arrival, or you'll hear a pop or hiss in the conversation. Furthermore, since a fully loaded MTA can simultaneously be compressing and decompressing up to eight multimedia streams, there are very few time slices available for security processing.
The first two revisions of the PacketCable security specification mandated that vendors encrypt Real-Time Protocol (RTP) audio streams with RC4 and Real-Time Control Protocol (RTCP) performance-monitoring streams with the Data Encryption Standard (3DES). While RC4 is relatively efficient, it has licensing restrictions. Furthermore, it is a stream-based protocol that relies on each packet containing an ever-increasing time stamp. (For instance, the encryption of every new packet is dependent on the encryption status of the previous packet.) If packets are lost or contain duplicate time stamps, stream-based protocols become vulnerable to attack (see Figure 5).
3DES is an ancient algorithm (circa 1981) that requires hardware acceleration to be viable. Although it is slow, 3DES does have a significant advantage over RC4 — it is block based. Block-based algorithms permit each packet to be self contained. Should an individual packet be lost or become corrupted, it doesn't affect the decryption of subsequent packets (see Figure 6).
During the time period when PacketCable was advocating 3DES and RC4, AES was generating a groundswell of support in the IETF. AES has proven popular because it is an open standard with no licensing fees, dramatically faster than 3DES (although slightly slower than RC4), and since it's block based, it isn't vulnerable to the stream limitations inherent in RC4. Fortunately, PacketCable dropped RC4 and 3DES in the third revision of its Security Specification and joined the IETF in adopting AES. This ensures that PacketCable MTAs will be able to interoperate with MGCP or Session Initiation Protocol (SIP) devices on noncable networks.
Another positive aspect of using IETF standards such as AES and Kerberos is that they enable economies of scale. To explain, since AES and Kerberos can be used on both cable and conventional IP networks, vendors will be able to sell their solutions to a larger number of customers and, therefore, drive down prices. These larger volumes will attract vendors who specialize in accelerating security protocols in hardware or software and will further increase performance.
Hacking cable telephony services not only impacts MSO profits, but also increases customer dissatisfaction and potentially slows down the transition to packet-based telephony networks. Therefore, to minimize the likelihood that the average user will attempt to steal services or disrupt the network, PacketCable has published its Security Specification. This specification relies on Kerberized IPSEC and SNMP to protect signaling information and AES to encrypt audio streams. Since Kerberos, IPSEC, and AES have broad industry support and are efficient, PacketCable finally has arrived at a specification that balances the need for security with rigorous timing requirements of packet telephony.
DDJ