May 1998

BY ERIC NEWMAN

The H.323 protocol for voice and video calls over the Internet, intranets, and local-area networks (LANs) promises to be a critical catalyst for acceptance of IP (Internet Protocol) telephony in the corporate environment and for service providers. With the growth of IP telephony, however, companies must be able to trust H.323 calls in the same way that they currently trust traditional circuit-switched voice calls.

Effectively securing H.323 involves more than protecting just the audio or video stream itself. Developers must also protect Q.931 (call setup), H.245 (call management), and Gatekeeper Registration/Admission/Status (RAS) to defend against tampering with the call control protocols. H.235, formerly H.SECURE, defines the standards approach for protecting H.323 traffic on the network. This key protocol covers authenticating users, protecting H.323 audio and video stream integrity, and securing the privacy of those streams. Vendor products need to take advantage of H.235 and other security measures to ensure privacy for the end user and to secure the corporate or service provider networks.

H.235 SECURITY OPTIONS
H.235 provides four options for adding security to H.323: authentication, integrity, privacy, and non-repudiation.

Authentication
Authentication is a mechanism designed to determine the identity of endpoints participating in the conference. Authentication can be used to verify that an endpoint is indeed a specific user or machine. Authentication is probably the most important concept in H.323 security — without authentication, anyone can enter a conference and represent themselves as someone else. In addition, the other H.235 security options described below cannot provide security unless the nodes in an H.323 call are first authenticated.

Integrity
Integrity validates a packet’s data payload to ensure that the payload was not tampered with or corrupted during the transit between endpoints in an H.323 call. This process is similar to checksums and CRCs (cyclic redundancy checks) used with other IP communications protocols; however, H.235- based data integrity utilizes an encryption mechanism to protect the packet’s integrity value. In this approach, only the integrity checksum value has to be encrypted, not necessarily the actual data payload, reducing the encryption processing needed for each packet.

Privacy And Confidentiality
While the integrity description will protect a packet against tampering, it does not protect the H.323 packet against intrusion. The encryption and decryption techniques standardized by H.235 provide a mechanism to hide data from eavesdroppers. If an encrypted packet is intercepted, it cannot be viewed without the appropriate decryption algorithm and, more importantly, the key to unlock the encrypted packet. The ways to encrypt data streams range from those that provide highly secure packets to those that provide a basic level of encryption. Determining the best way to encrypt the streams usually involves a trade-off between level of security and computational expense. Often, the more secure the encryption, the more complex the mathematical algorithm and the more processing power (and added latency as a result) required to encrypt the packet. Ultimately, end user requirements for security and national laws can also limit encryption levels.

Non-Repudiation
Non-repudiation provides protection against someone denying that they participated in an H.323-based call. As with a shipping company that requires a signature when they deliver a product to your doorstep, once users sign the way-bill, they cannot later deny receipt of the package. Non-repudiation is especially important for service providers who need a way to accurately charge for their service and validate those charges against a user’s activities. Note that H.235 has not formally addressed this issue in the version that was standardized by the ITU (Internet Telecomunications Union) in February 1998, but it has been marked for future study.

ACCOMPLISHING H.235
Key Exchange
Keys are of paramount importance to H.235. At the heart of authentication is the ability to exchange keys between secured H.323 nodes on the network. In addition, packet integrity and stream encryption and decryption systems utilize keys as the way to make each encryption/ decryption uniquely unbreakable. Without a key, the recipient has no way to understand how the packet was encrypted and will have no way to unlock that packet to read its encrypted contents.

As with most security mechanisms, more than one way exists to exchange keys. The key exchange methods used for H.235 can be broken down into three distinct categories.

Out-of-Band: In this approach, the key for unlocking the encrypted H.323 packets is sent via e-mail, word of mouth, or by some means other than an H.323 protocol. Out-of-band key exchange can be the most effective means of security because passing the key personally between two people and their computers in a direct, local link is the only way to truly keep a key hidden from intruders. However, this approach can easily break down if people use unsecured key passing methods, such as e-mail and audio phone connects, both of which can be tapped if left unprotected.

Diffie-Hellman: Realizing that e-mail or other traditional communication methods are not necessarily secure and that a direct link is often not feasible, other key exchange systems have been developed for passing keys in a secure fashion. The Diffie-Hellman Method For Key Agreement allows two hosts to create and share a secret key.

Oakley and ISAKMP: The Oakley Key Determination Protocol uses a modified Diffie-Hellman technique to establish session keys on Internet hosts and routers. Oakley can be used by itself or in conjunction with the Internet Security Association and Key Management Protocol (ISAKMP), which provides a framework for Internet key management.

Note that the H.235 standard does not promote one key exchange technique over another. In fact, H.235 defines an appropriate H.323-based protocol set that facilitates key exchange, but allows the developer to choose which type of key exchange to use in a product. As a result, market leaders will likely select one method of key exchange as a de facto standard in the early rollouts of H.235-enabled H.323 products. Which method they will choose remains to be seen. However, as the different security camps in the market converge, most product developers will want to support different types of the most popular key exchange methods.

H.323 PACKET ENCRYPTION
Software developers have two choices when it comes to protecting the privacy of the H.323 protocol and streams packets. They can roll security into their own private protocol, or they can use an external mechanism to encapsulate their data packets in a secure manner. In the latter approach, TLS (Tansport Layer Security) and IPSec (IP Security Protocol) encapsulation techniques allow software application developers to largely ignore security when writing their applications.

APPLYING H.235 SECURITY TO H.323
With all of these security technologies in mind, the logical next step is to effectively secure H.323 products and services. When implementing security in an H.323 environment, developers need to consider the following components in determining what their best approach will be.

RAS Servers
RAS is an unreliable UDP-based transport mechanism. RAS messaging servers help client endpoints (terminals, gateways, and MCUs) communicate with a Gatekeeper so that the Gatekeeper can facilitate management of the endpoint and its requests for service. From a security perspective, developers need to address two issues with RAS — preservation of the integrity of data within RAS packets, and authentication of endpoints. Privacy (encryption and decryption) of normal RAS payload data is not addressed in H.235. Because the H.235 definition for use of integrity techniques to preserve RAS packet data is also incomplete at this time, only authentication remains as an issue for developer concern today.

Symmetric Encryption-Based Authentication: Requires no prior contact between the endpoints. The Gatekeeper uses this form of authentication to validate subsequent Gate-keeper directed requests and verify that the requests are indeed from a node that was previously registered. It does not provide a mechanism for the endpoints to validate that the Gatekeeper is indeed "the" Gatekeeper. Symmetric encryption-based authentication is a one-way form of authentication used by Gatekeepers only.

Subscription-Based Authentication: Requires some prior contact or information dispersion between the end- points. This dispersion can be accomplished using passwords or digital certificates with signatures. This approach is bi-directional in nature, which means that both endpoints can be authenticated. Each endpoint possesses a well-known text string identifier to uniquely identify itself.

Q.931 Protocol
The Q.931 protocol uses a reliable IP transport-based mechanism for packet delivery. The role of Q.931 messaging is to originate the first of many possible legs in a point-to-point communications scenario between two endpoints. Three categories exist where H.235 security can be utilized for Q.931. First, H.235 integrity protection techniques can prevent tampering with the Q.931 packets. Second, H.235 allows for complete encryption of the Q.931 streams. And finally, H.235 helps utilize user authentication to verify end-points as the call setup packets begin to move across the network.

H.245 Security Issues
The same methods for securing Q.931 apply when protecting H.245 packets. These methods include protecting the integrity of the H.245 packets, authenticating users, and even encrypting the entire packets for privacy purposes. Interestingly, Q.931 actually negotiates how the H.245 control channel is managed in a secure manner. The originating Q.931 endpoint places "all" of the well-known, defined, and supported mechanisms it could use to secure the H.245 channel in its "h245SecurityCapability" entry (SETUP PDU).

Streams (RTP/RTCP) Security Issues
Once the video and audio RTP streams begin to flow, encrypting those packets is the most logical security measure to take. Note, however, that encryption can be very processor-intensive. As a result, any offloading of streams encryption will help prevent undue latency buildup in H.323 audio and video streams.

As demand from corporations and service providers for IP telephony solutions grows, increasing numbers of developers will look for easy-to-implement H.323 security measures.

H.232, the ITU-T protocol for managing and faciliating packetized voice and video over a local-area network (LAN), has quickly become a lynchpin in the growth of interactive voice and video communications and telephony over intranets and, increasingly, the Internet. H.323 consists of several underlying standards:

• H.235: TAckles a variety of security issues for the specific H.323 protocols (Q.931, H.245, RAS, Streams). H.235 was formerly called H.SECURE.
• H.245: Handles connection management and capabilities negotiation between H.323 devices on the network once the call is set up by Q.931.
• Q.931: Provides a protocol definition for setting up and tearing down H.323 calls.
• RAS: Registration/Admission/Status facilitates communications between H.323 endpoints and H.323 gatekeepers. Gatekeepers are H.323-based network infrastructure devices that help facilitate and control H.323 across networks.
• RTP/RTCP: Real-time Protocl/Real-Time Control Protocol serves as the standardized means for transmitting and receiving audio and video streams across the network once the call is set up.