Internet-Draft | RSA Authenticated Encryption | May 2021 |
Albert | Expires 2 December 2021 | [Page] |
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.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶