Internet-Draft RSA Authenticated Encryption May 2021
Albert Expires 2 December 2021 [Page]
Intended Status:
Standards Track
N. Albert

AES-128 Encryption with IAX2 (Inter-Asterisk Exchange 2) Authenticated Using RSA in Peer-to-Peer VoIP Environments


This document specifies a mechanism which allows for peer-to-peer Voice over Internet Protocol (VoIP) using the Inter-Asterisk Exchange version 2 (IAX2) protocol to be authenticated and encrypted in the strongest possible way currently feasible in Asterisk, an open source communications toolkit.

This allows for stronger authentication of call and ensures a more secure call setup. The encryption standard used, AES-128, is consistent, ceterus paribus.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 2 November 2021.

Table of Contents

1. Introduction

1.1. The Problem

VoIP call traffic is, in the simplest case, unauthenticated and unencrypted, which means that calls are essentially sent in plain text over the wire, and can be monitored by any third parties with access to the data traffic or captured and reconstructed at a later point in time. This offers no privacy to the participants of a call and is even less secure than using a conventional phone line, given the prevalence and ubiquity of IP capture tools today.

Encrypting VoIP calls adds the same level of security to telephone calls that certificates and TLS do for web traffic, by ensuring that only the participants in the call have access to the data. This protects the participants from eavesdropping and provides a higher lever of secure than that possible through conventional public phone networks.

The IAX2 protocol is commonly used for trunking between Asterisk systems. It provides for several security features, namely call tokens, host restrictions, authentication, and encryption. Call tokens [IAX2-Security] were a later addition to the IAX2 protocol that helps prevent denial of service attacks. Host restrictions limit allowed traffic based on predefined IP address or hostname-based restrictions. Authentication uses secrets on both ends to authenticate the server originating a call. Encryption is an enhancement to authentication which uses AES-128 encryption to encrypt the media stream.

There are currently four possible levels of authentication.

  • The first is no authentication at all, and this is the default.
  • The second is plain text authentication, which requires a plain text secret to be sent over the wire. This is now deprecated in newer versions of Asterisk.
  • The third is MD5 authentication [RFC1321], which uses a challenge-response mechanism to authenticate.
  • The fourth is RSA authentication, which requires that the server receiving a call have a public key on file for the server originating the call.

Historically, it was not possible to use RSA authentication in conjunction with encryption. It was only designed for use with MD5 authentication in mind. This was unfortunate, since RSA authentication allows for a higher standard of authentication to be used and, in conjunction with AES-128 encryption, would offer the highest security. This issue was addressed by a 2014 patch which is in the process of being merged into the project as of this writing by PhreakNet.

RSA authentication configuration was designed primarily with static trunking between nodes in mind. In dynamic peer-to-peer networks using an external source for routing, trunking needs to be configured dynamically so that it is possible for such trunks to be created on the fly for use. This poses difficulties with RSA authentication, since all of the information required for an RSA-authenticated call cannot be provided dynamically to the Dial application in Asterisk, but must reside in semi-permanent resident configuration.

1.2. Dynamically Configured RSA Authentication Configuration

This specification addresses the problems discussed in Section 1.1 by reviewing a general mechanism and strategy which may be used for dynamically - that is, automatically - handling configuration of RSA trunks in Asterisk, keeping in mind that such configuration could be introduced or changed at any point in time.

There are three separate components of such a framework that facilitate this capability.

  • Key server. A key server, accessible to all nodes in the peer-to-peer VoIP environment, is required. Key pairs on each node will need to be generated and the public keys need to be uploaded to the key server, potentially manually. This only needs to be done once for each key pair, unless that pair later changes in the future.
  • Outgoing calls. An outgoing call from A to B requires that A be able to provide its private key for the call to B and B be able to verify A's public key. A has a single private key that is used for all outgoing calls. Although Dial supports providing the name of a secret directly in the dial string, it can only be done if a secret is not provided. Historically, MD5 authentication + AES-128 encryption would use a secret and RSA authentication would use the name of a private key (or outkey), so there was no conflict. Since the addition of AES-128 encryption support to RSA authentication, both parameters are required and thus currently, all information required cannot be specified in the dial string. This is subject to change in the future if the syntax is updated to account for this. To overcome this limitation, the dialplan dynamically writes out the necessary configuration to a configuration file and then reloads the IAX2 channel driver as well as the res_crypto module. Then, the call can proceed.
  • Incoming calls. An incoming call is the more complicated of the two cases, since B will need to be able to verify B's public key, but it may, as of yet, have never received a call from B before. There are two approaches that could be used. One entails all nodes in a network periodically updating their local caches of all the public keys available for the network. A call will fail if a call is attempted before B has had an opportunity to pull A's private key. A second approach is to provide that the first call between A and B will always fail, but the call should gracefully fall back to using MD5 authentication + AES-128 encryption. This will provide B an opportunity to know about A and then download A's public key at that time. On the next such call from A to B, B will be able to verify A's public key against its list of allowed public keys and can accept the call.

A second way of handling the difficulty of authenticating incoming calls is to to store private keys on the key server instead of public keys. Then, A could pull B's private key to complete the call, which B would accept, de facto. While this simplifies the process significantly and increases the RSA-authenticated call completion rate to 100%, it defeats the intent of asymmetric authentication and results in significantly worse security. Therefore, we reject this approach in favor of that described above, even though it involves more overhead, precisely because it is able to utilize public key cryptography in the correct manner to facilitate call setup.

The exact approach and implementation is not dictated by this specification, only a general mechanism that may be used to facilitate the use of RSA authentication in dynamic environments. This is not limited to the use of encryption in any way, but is most useful in contexts that require some level of security.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Security Considerations

MD5 authentication is widely considered weak and deprecated by today's security standards [RFC6331]. RSA authentication is significantly stronger and considered sufficient by modern security standards. Because it requires additional configuration and is asymmetric, it is more complicated to configure, especially in dynamic environments. The mechanism discussed allows these limitations to be easily addressed and can facilitate a more rapid adoption of RSA authentication in Asterisk on IAX2 trunks now that it is no longer mutually exclusive with the use of AES-128 encryption.

4. References

4.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

4.2. Informative References

Davenport, M., "IAX2 Security", <>.
Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, <>.
Melnikov, M., "Moving DIGEST-MD5 to Historic", RFC 6331, DOI 10.17487/RFC6331, <>.

Authors' Addresses

Naveen Albert
United States