I’ve been communicating with the nice folks at IANA (Internet Assigned Numbers Authority) to try to get official recognition for an ED25519 authentication method in IAX2. My submission is linked here:
It’s not that profound, but if anyone has comments please feel free to share them.
is not IAX2 only being kept around for backwards compatibility with old installations? My understanding is that at the moment it’s mainly used for inter-Asterisk trunking and nothing else. Without new implementations being built that incorporate this extension what is the point of this proposal?
Hi Ted. The Amateur Radio community has a large (>10,000 node) IAX2 network that is used to link radio systems around the world. Most of these nodes run an extended version of Asterisk, but there are a few non-Asterisk implementations of the protocol as well. You can learn more at: https://www.allstarlink.org/
I am working on a new, non-Asterisk implementation of IAX2 which is described here: Ampersand Linking Project | Bruce MacKinnon
My IAX2 implementation incorporates several extensions, so I care about IAX2 and am trying to pass my improvements through the Internet standards process.
For better or worse, IAX2 is very much alive.
One fact that hasn’t changed, is that IAX2 is easier to tunnel through NAT than SIP. It’s just one UDP port. I realize SIP is now long-established as a known quantity, and everybody knows all the procedures for dealing with the headaches. But that doesn’t make them completely go away.
IPv6 makes NAT go away and for any new networking you need to be compatible with it.
I’m not qualified to argue the merits of IAX2 vs. SIP, so don’t interpret my messages as trying to argue the superiority of IAX2. 
One guy’s opinion from watching “average people” (not network/VOIP admins) setup/build various VOIP systems: IAX2 is easier to get up and running than SIP for peer-to-peer networks. It’s not just a NAT issue, there are also firewall issues that have to be considered.
And yes, I agree, IPv6 makes things a bit easier.
There’s also the issue of protocol complexity for constrained devices (i.e. microcontrollers and portable stations).
It’s probably not a coincidence that neither of the largest VOIP linking networks used in the Amateur Radio community (EchoLink and AllStarLink) are SIP-based.
What about encryption?
Encryption would imply non-public use of the HAM airwaves which is in violation of the law at least in the US
I agree, you are right. I was not aware of that part and only looked at the protocol level. Thank you for your response.
It would be more useful to have that option, than not.
Even if the radio hams can’t use it, doesn’t mean others mustn’t do so.
Hi again Ted. I think you are getting confused. The FCC regulations (US) prohibit encryption over the airwaves, but this is completely unrelated to the digital voice/data links that are often used to link radio systems. The ham radio community uses Asterisk for linking radio systems over the internet and/or private IP networks and there are no limitations on encryptions in that space. In fact, many hams run these links over secure VPNS and other encrypted mediums.
Hi: If I am interpreting your question properly, I think you might be asking about the encryption of the call (audio) traffic itself. That is a good point, but is a separate part of the protocol that will be handled through a separate amendment to the RFC which I will publish later. The ED25519 stuff that is the topic of this thread is for asymmetric encryption used for authentication (i.e. PKI handshakes). So it wouldn’t be that relevant to ongoing call traffic.
And to avoid any other confusions here, my main motivation for proposing some of these more modern primitives for authentication (ED25519) or encryption (something different from AES-128, potentially ChaCha20) is not because I am feeling that the current specification is insecure. The issue is related to complexity/capacity on very small devices. I am running the IAX2 protocol on a small ARM microcontroller and it’s nice to have secure but very light-weight crypto primitives.
Thank you all for your consideration.
Well there is your answer, then. Not needed because it’s already being done better by something else.
I think the experience with the package uw-imap and encryption should be a warning on this.
uw-imap was the first original implementation of the IMAP4 protocol, the author Mark Crispin was also the author of that protocol, it was the reference implementaiton.
Over the years people who thought like you started heavily pushing the idea of requiring encryption into the IMAP protocol standard. Eventually, in one of the later RFC’s Mark authored, he was badgered into doing this. But at that time most of the Internet clients were not using encryption so uw-imap was modified to allow it to be built either way - with or without SSL. In order to appease the people like you a complicated script was stuck into the makefile basically saying “I see you disabled SSL are you SURE you want to do this?”
Well things seemed to go along OK for a while. successive versions of OpenSSL were released, uw-imap was buildable with them, and people like you were appeased while the rest of the Internet built uw-imap with both encryption and unencryption available.
Then other IMAP packages started appearing and Mark died and the uw-imap code became sort of orphaned. But it still built.
Then one day around OpenSSL 1.1.1 days, the OpenSSL devs changed the API. Breaking uw-imap. A patch was released - it worked for a while - but for some reason it does not work with successive OpenSSL versions. the uw-imap package started to be removed from maintainer distros and today only the client part of it is left which may or may not work. And today the world’s CA’s are now trying to force auto-renewals of certificates to they are cranking down expirations of certs to months now instead of a year. Encryption is increasingly getting to be a tremendous nuisance to handle for anything other than running a web server like Apache because of the automatic renewals. And this is just on Unix operating systems where you can hack together scripts. For commercial software (like Exchange) they now are basically making you tremendously hack together cert renewals with power shell garbage that’s not reliable or pay for commercial programs that are all delivered vis subscription so you now are basically paying a second “subscription” to those programmers in addition to the CAs
You can, today, compile the original uw-imap code, setting the flag that disables including OpenSSL and it builds and works. But it is badly broken for encryption. And the amount of other packages that have had to be reworked just because OpenSSL devs did something is very high. And by getting dependent on SSL now we have all the overhead of adminstration of certs.
ANd yet, people are STILL to this day being scammed, their encrypted credentials are STILL being stolen, even off completely secure SSL sites. The promise of the commercial CA’s was go to https and it will end all of the scamming. But that has not happened the scammers are still scamming, instead now we have a huge layer of encryption beaucracy we didn’t have to deal with either that is locked in using “save the children” arguments that the weak-minded fall for.
If you are so hot for encryption IAX2 then nothing is stopping you from doing it with SSLeay. That software is designed to encrypt network protocols. It is no less secure and light-weight than compiling OpenSSL into the server itself. And most importantly it is a separate package, so the SSLeay code isn’t contaminated by dragging the IAX2 code into it, and the iax2 code isn’t contaminated by dragging openSSL into it. The border cases like you who want encryption of IAX2 can get it without the overhead of a VPN, while the rest of us don’t have to deal with futzing around with running our own CAs and distributing certs or fiddling with certbot and the large CA’s current encryption-o-the-week rules.
Hi Ted. It sounds like “people like me” have caused a lot of problems for you. Hopefully I’m not making things any worse with this thread. And thanks for sharing that fascinating history of uw-imap.
I’ve had a lot of good input on this and my other threads. Just so I’m clear about what you are recommending, are you saying that it’s a bad idea for me to be working with the IANA team to get another authentication an/or another encryption type added to the registry for IAX2? My proposals relate to the standards document and I’m certainly not proposing any changes to Asterisk project itself, so you can rest assured that the Asterisk code won’t be “contaminated” by anything I am doing.
The IANA people have been very helpful and have not yet raised any concerns about getting the protocol extended with a few new options. But I’m always interested to understand counter-arguments.
Thanks!!!
I don’t understand all this “hack together scripts” business. Who is still paying money for CA certs? We just use Let’s Encrypt, which is very easy to set up on a Linux system (standard packages are available on Debian and derivatives), and won’t cost you a cent.
As always, a system is only as secure as its weakest point. Don’t blame TLS/SSL for weaknesses elsewhere.
It depends entirely HOW it is added.
The problem with the updated RFC for IMAP, is that it basically made encryption mandatory during an era when hardly anyone was running encryption on connections from Email clients to ISPs. You also had a situation where most people were running Dialup still, most were running IMAP email clients that didn’t even support encryption and most users on the Internet were using desktop versions of software at fixed locations, and as a result, the idea that a cracker would be able to tap into their unencrypted data stream going from their email client to their ISP, over their ISPs network, was extreme fantasy. However, the “it’s for the children” crowd exploited their Chicken Little arguments and the bugabo spectre of “The cracker bogeyman” to force encryption into IMAP as mandatory and then use the new RFC to beat every developer of email client software that supported IMAP over the head to add encryption into their offerings.
Obviously, there is an argument to be made FOR encryption - but - I don’t appreciate it when people come along (the self-appointed Gods of IMAP in that case) and claim that they know better than me how I’m supposed to be securing my credentials and so they are going to force me to do it their way because they know better. Do you see what I am talking about, here?
Because of this, Mark Crispin bent over backwards and put a nutty build script into uw-imap that basically when you set the build flag that turns off inclusion of OpenSSL libraries, asks “are you sure are you sure are you sure” and you have to hit “Y” multiple times to actually get it to build without the libraries. That is a recognition by Mark that there were PLENTY of people out there who felt exactly the same way as me. So, it ISN’T as you seem to be saying “sounds like “people like me” have caused a lot of problems for you.” It is, in fact “sounds like “people like me” have caused a lot of problems for MANY OTHER PEOPLE”. I just want to be clear about this. I am relating my direct experiences with heavy-handed “technical religious zealots” forcing standards changes based on “sky is falling” and “cracker bogeyman” arguments as EXAMPLES but I am NOT saying - as you implied - that it affected me only. It affected a LOT of other people and caused problems for them, too.
Now, obviously, the landscape for IMAP today is 100% different. IMAP4 has been out there now “longer than your grandpas rawhide rubber” as the saying goes, every known email client still in use supports encryption, the fur has flown in that fight, so requiring it is a no-op. Also, that encryption fight occurred in the nascent days of Internet email, so just because of successive growth if something got jammed into a standard early, it would “stick” even though a lot of people might be inconvenienced about it.
But in the IAX2 situation now, well as I see it, IAX2 seems to have stuck around basically because, boiled down, it can move digitized audio in a phone call over the lower bandwidth ham bands better than SIP. Otherwise, it would have been obsoleted. I assume this is because the protocol is simpler, or it is more resilient, or it requires less CPU power, or something of that nature. You would know better than me I think. So I am saying - if you are engaged with IANA to create a standard for encryption to IAX2 - you need to be very, very cautious here and NOT repeat the IMAP mess.
I believe you are going to have to produce a reference sourcecode for an IAX2 driver that plugs into Asterisk and that links into OpenSSL in order to demonstrate working encrypted trunks over IAX2 before IANA or IETF or anyone else even accepts this as a standard. I am saying, when you do that - make encryption optional, and make encryption optional in the standard. Don’t require it and don’t do what they did with IMAP where it basically forces you to run encryption even though the actual letter of the standard may use the verb “may” instead of “must” (I am not going to spend a lot of time digging around in dusty old standard documents to have a semantic argument, BTW) And, I am also saying, you can do encryption RIGHT NOW on IAX2 using SSLeay, so it might also be useful to set that up now and test on it, just to demonstrate it works.
You do know the Internet is a lot bigger than just Linux-only systems, correct?
Just to point out a few things on this:
A lot of internal-use only websites at corporations are running on Windows Server, and using platforms other than Apache.
A lot of the major commercial shopping cart sites on the Internet (that sell shopping cart systems with payment built in) are used by commercial entities that have to use commercial certs that carry insurance on them in order for their own cyber insurers to cover them.
Anyone running on-premise Exchange Server (which is virtually all Fortune 1000 and a hell of a lot of smaller orgs than that, particularly since Microsoft has jacked O365 fees up into God’s azz) is likely using a commercial cert because Microsoft did no integration of the ACME protocol (needed to obtain LetsEncrypt certs) into Exchange or into Windows Server.
The world’s commercial CAs are all moving to use of ACME and other proprietary automatic cert-issuing protocols for ALL certs because it reduces support calls to them and it makes their product easier to access for customers
Let’s Encrypt’s servers are mainly paid for by Google which is the single largest donor of the non-proft that runs Let’s Encrypt. Google’s interest is because they wanted EVERY WEBSITE ON THE INTERNET to be HTTPS. They did not do this for altruistic reasons but for dirty money-grubbing reasons (which I’ll explain in a moment) Once that happens, then those websites will NEVER shift back to unencrypted HTTP - thus there is no more need for Google to have the cash-drain of Let’s Encrypt - so it is highly likely that they, and the other corporate donors funding Let’s Encrypt, are eventually going to scrape the Let’s Encrypt non-profit off their shoes. And when that happens - Let’s Encrypt’s only option will be to start charging money for certificates - just as what happened with the Doman Name system (believe it or not, domain name registrations USED to be free! I know, I know - Grandpa Ted here has gone off his rocker again - that’s what you all think. But, CA servers and infrastructure and the butts of techs in the seats needed to keep it running all costs money - everyone has to eat you know - and that money comes from somewhere.
I know a lot of admins think that all this encryption stuff is always going to be free as in free beer. But that is naieve rubbish. You have to have developers and techs to keep this infrastructure all running and they have to be paid and that money has to come from somewhere. Asterisk found that out which is why Sangoma exists. That’s a good solid relationship and the majority of commercial customers of Sangoma’s products don’t want to learn anything they just want to be told what to do to get a PBX running and are willing to pay money, thus some of that money pays for devs to put time into Asterisk. Great system and I shouldn’t have to be lecturing/reminding anyone here of that.
Now try to think about how Let’s Encrypt is funded. it’s funded by Google taking those zillions of FREE copies of Chrome out there and instrumenting them for URLs people are typing in, then selling all that gathered data out the back end to marketing types. As well as just blatantly selling advertising on search results and so on. Google does NOT want competitors (like firewall vendors like Palo Alto, Fortigate, etc.) accessing those URLS and selling their own marketing data, it does not want ISP’s also intercepting those URLS and aggregating it and selling that marketing data, basically it does not want the competition. So, they pay a chunk of money to fund Lets Encrypt and hand out free certs, we all use them, and those URLs are now protected from the competition accessing them and selling them to marketers, thus it kills Google’s competition, Google can continue to be a monopoly, etc.
That’s why Let’s Encrypt certs are free. Google and these other deep pocket donors to Lets Encrypt are NOT doing this out of the goodness of their hearts for all of us to benefit. Get it now?
Hi Ted. Thanks again for your very detailed input on this topic.
I’m not sure if you’re speaking from experience here. In all of my discussions with IANA on this topic to date, nobody has mentioned the need for reference source code or anything that plugs into Asterisk. Maybe there’s a step that I haven’t made it to yet.
It is my understanding that Internet RFCs are expected to define protocol standards in a way that is entirely independent of implementation. And most certainly independent of Asterisk and/or OpenSSL. The nice thing about these protocol standards is that they let people interoperate without a common implementation. Honestly, I know very little about Asterisk and even less about OpenSSL, and yet I have been able to follow RFC5456 (BTW, my copy isn’t dusty at all) and have created a implementation of the IAX2 protocol - including relevant encryption - that runs fine on a $8 (USD) microcontroller and can place calls to many other folks who are running Asterisk servers.
When you get a chance, you should take a quick read through the IAX2 RFC. That document, and my proposed amendment to it, makes it very clear that these authentication/encryption features are optional. Unless I’m missing something in that document, I’m sure there’s no reason to fear anyone forcing encryption on you. But I’ll keep an eye out for that.
Have a good day!! Bruce
Not really, no. The Internet primarily runs on Linux these days. That’s just a fact.
There are lots of webservers, besides Apache, available on Linux and *nix platforms, that interoperate fine with Let’s Encrypt.
As for users of non-*nix platforms, if they want to make things difficult for themselves, that’s their problem.
This I don’t understand at all. If the insurance is on the cert encryption algorithm being broken, well, nobody can realistically expect a payout on that, can they? And if the insurance is on the whole security system of the site (which seems to be the only reasonable way to do it), then there will be other, more important potential sources of vulnerability to worry about, anyway.
I have provided services for clients setting up online shops. The first one was back in the days when Mark Shuttleworth’s company, Thawte, was operating out of his homeland of South Africa, offering SSL certs at a lower price and with stronger encryption than Verisign in the US was able to offer. Nobody insisted that we get Verisign certs, whether for insurance or any other purposes.
If Exchange Server makes it more expensive and complicated to maintain proper security, then anybody who stubbornly persists in using Exchange Server is not exactly making the optimal decision for their organization, are they?
I don’t see that as a problem. Remember, all the protocols are open, with readily-available open-source implementations. That means, as soon as the existing Let’s Encrypt organization starts to act in ways contrary to the interests of its users, another outfit will inevitably arise to offer an alternative service. And switching to that new provider is just a matter of changing a few config files.
Furthermore, I suspect a lot of the existing Let’s Encrypt personnel will readily volunteer their skills and time to help set the new organization up. And abandon the old one.