Alan DeKok's RADIUS Blog

I recently saw an article on Network World: Identity Engines goes under. They had a nice product (in some ways), but there were a number of things I didn't understand about what they were doing.

1. They wrote their own RADIUS server.

   Huh? It's 2008. There are many RADIUS servers that they could download for free off of the net. Some are BSD licensed. Others (ahem) like FreeRADIUS are GPL'd. Isn't it always good shareholder value to build on top of what other people have done, like using Linux, Apache, MySQL, etc. This is cheaper, faster, and more reliable than re-inventing the wheel. Again.

2. Their business model.

   It was based on selling "high availability" RADIUS servers to enterprises. I've been in the space for over a decade, and I know how many RADIUS servers are needed in a typical enterprise: 2 to 10. Even if they captured 100% of that market, they would likely sell only a few thousand boxes. And they didn't even do that.

3. The value it has for their customers.

   To quote the Network World article, their product:

   ... features a number of APIs to tie easily into a range of backend lookup and authentication services. A policy management engine centralizes policy creation and distribution, and other features enforce policies on users, including mobile or remote users...

   Isn't that what all RADIUS servers do? FreeRADIUS has been doing exactly that for almost a decade. And, it's more flexible and more scalable (to say nothing of cheaper) than commercial "box" solutions.

So on one hand it's sad to see them go under. They had a relatively good product that solved some customer needs. But there wasn't enough business to keep a company running.

On top of that, they went through $26 million in VC investment. Hmm... FreeRADIUS became the number one RADIUS server on the planet with zero funding. Just imagine what we could do with a paltry $26 million!

To everyone who had bought a server from ID Engines, please consider switching to FreeRADIUS. We even started a company to do support and development. Multiple Fortune-50 companies already use our solution. We think you should, too.

We've been trying to release 2.0 of FreeRADIUS for a long time now. The 1.1.0 release stream started three years ago. This time last year, I was prepared to say that version 2.0 would be released “very soon”.

I was wrong.

But wow, what a difference those extra months have made. New features like unlang, and virtual servers make it almost… easy to configure the server. Many policies can now be created almost as fast as you can type them in. Complex interactions between policies can be avoided in many cases. It feels like a whole new product.

A number of people have been using pre-releases in production for the past few months, so we can say with confidence that it's stable, too. It has gone through a source code audit, and a formal scan, which means in addition to being stable, it's secure.

With the release of 2.0, it's feature set is simply better than any commercial or open source RADIUS server. It supports more EAP types, more databases, scales better, more flexible, is more widely used than anything else. That's a good place to be.

RFC 5080 has just been issued. It's been in progress for over three years now, so I'm personally very happy that it is finally done. As a co-author, it's nice to see it published. As someone who has been working with RADIUS for a long time, it's nice to be able to point to a document that clarifies problems or inconsistencies in previous RFC's.

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.

Section 2.1.1 (no hyperlink available yet) documents the practice first implemented in FreeRADIUS: simplified handling of EAP sessions in RADIUS servers. To my knowledge, all RADIUS servers today follow the FreeRADIUS method of handling EAP sessions… even large commercial products.

So if a commercial vendor ever puts down FreeRADIUS, you can politely point out that their software is following our lead.

I recently heard an interesting story about a large FreeRADIUS deployment. The company started using FreeRADIUS a number of years ago after some investigation into alternatives. One commercial solution would have been over a million dollars, which seemed a bit much. When they chose FreeRADIUS, their partners responded with “Oh, no! You're using Open Source? That's not good!”.

Their partners were, of course, using commercial solutions.

Today, all of their partners are using FreeRADIUS. Things change.

When I talk to people, the attitude now is “Of course you're using FreeRADIUS.” On top of that, FreeRADIUS is setting standards in the RADIUS space. Switch vendors are pushing to add more features to the server, such as WiMAX.

Honestly, I don't see an end in sight. The server will continue to get more useful, more powerful, and will continue to increase its market share and its industry leadership.

OK, so it's been a while since I posted that 2.0 should be available “soon”. The wait has been worth it, though. The first “magic” feature is in: VMPS support. It's not a huge addition, but it's useful in certain contexts. The next “magic” feature is in testing, and should be deployed in sites totalling 100k users within a month.

The other changes have made 2.0 feel a lot more like a major revision over 1.x. There is now virtual server support, similar to Apache's virtual servers. But we feel it's more powerful. FreeRADIUS can now have completely different personalities for each port it listens on. For EAP-TTLS and PEAP, the inner tunnel session can be run through a completely different configuration that the outer session.

And there's a new “un-language” in the configuration files. See “man unlang” in the recent CVS versions. It supports complex conditions for matching policies. It can edit any attribute list (request, response, etc) with ease. It removes the ~256 character limitation on expanded strings…

It's at the point where I can't see how I could go back to using even 2.0 from 3 months ago. I think everyone should take a serious look at 2.0 when it's finally released.

I can't finish this blog entry without mentioning the people who's feedback has helped enormously. Arran, Milan, and Doug, your efforts are appreciated enormously. Thanks.

The past few weeks have seen a major shift in the code base of FreeRADIUS. The old code that performs a linear walk over all of the “live” requests is gone. Its replacement is a timed event subsystem that only does what is necessary, when it is necessary. As these things usually go, the new code is smaller, cleaner, more modular, and easier to understand than the old code. The hard part isn't writing the code. The hard part is coming up with a better design.

Other cleanups include major fixes to the proxying code. Home servers are now independent of realms, which means that they can be used by multiple realms with minimal configuration. If a proxying server notices that a home server is dead, it can now send “are you alive?” messages periodically. Once the home server responds for a configurable time, it is marked “alive”, and put back into the usage pool. In addition, when any home server is marked “dead”, the requests which were being proxied to it get re-written to use another home server from the same pool. These two features mean that proxies will become much more robust and “transparent”. i.e., they will Just Work, which is one of the philosophies behind the server.

More SNMP statistics have been added. The server now keeps track of many more counters for the RADIUS MIBs, meaning that it is easier to monitor the behavior of the your RADIUS installation.

There are also a few “magic” features I'm trying to finalize before the release. I won't say much more, but one should cause some amount of surprise when its added. Stay tuned for more details.

There hasn't been a security problem with the server in over a year (barely). That's good, but we'd like it to be better. Therefore, we've started working with Coverity, makers of source code analysis tools. They host an open source scanning site, and have recently added FreeRADIUS to the mix.

The announcement came as part of their one-year anniversary of scanning open source projects. The bad news is that they found bugs, which is not entirely surprising. The good news is that none of the bugs have security implications, and that we're working on fixing all of them.

The goal is to have Coverity show a scan result of zero bugs before 1.1.6 is released. We'd like to get a “pre-scan” of 2.0, so that it also has zero bugs. This doesn't mean that the server will be bug-free, as there may still be logic errors in the code. What it does mean is that there should be no security bugs in the server.

I'm at IETF 68 in Prague. I'm sure Prague is a nice city, but I'm not seeing much more than the conference hotel, and a few local watering holes. I always liked the move “Kafka”, and wanted to go see the sites where various scenes were shot. Maybe next time.

The IETF meetings, though, are enlightening. I haven't been following many standards groups, but when I sit in on the meeting rooms, I noticed that AAA was everywhere. And most of it was RADIUS.

I think the network is at the point where network protocols are converging. In order to do anything in an authenticated, accounted, secure, manner, there's a minimum set of things that have to be done. The result is that it seems most protocols now include references to other protocols to enable this, that, or the other thing. (Sort of like my RADIUS + DTLS draft, which proposes to solve the RADIUS cryptography problems by using TLS.)

The wide-spread use of AAA means I'll have to follow more working groups, and do so in more detail. What impact this has on my free time is yet to be determined.

The good news is that I'm finding more time to work on the book, and on FreeRADIUS. I'm now targetting the book at Version 2.0, with the idea of releasing the book shortly after Version 2.0 comes out. I hope both happen soon.

After a decade of working with RADIUS, and almost 8 years of driving FreeRADIUS, I'm happy to say that FreeRADIUS will finally be mentioned in a standards-track RADIUS RFC. The draft is titled “Common RADIUS Implementation Issues and Suggested Fixes“, and it is currently in “last call” on the IETF RADEXT working group. The document is a “grab bag” of topics, and covers a wide variety of issues in the RADIUS space.

The abstract says:

This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.

I expect that this document will become one of the canonical must-reads for RADIUS implementors. The guidelines it proposes, and clarifications it covers are the result of years of real-world experience with RADIUS implementations.

Plus, it mentions FreeRADIUS! Section 2.1.2 of the document describes an algorithm for managing EAP sessions that was first implemented (so far as I know) in FreeRADIUS by Raghu Dendukuri. The previous method documented in the RFC that defined EAP over RADIUS was complex and fragile. Raghu's design is beautiful in its simplicity. It's so good, in fact, that all RADIUS servers now implement his system for managing EAP sessions.

Not surprisingly, when the opportunity came up to write this document, I jumped at at. It means that I get published as the author of a RADIUS RFC, and that the “FreeRADIUS way” becomes documented as an industry standard. So FreeRADIUS is now officially an industry leader in the RADIUS space!

MySQL AB has announced that they are preparing for an IPO this year. The points I picked up on are:

• An install base of 10 million site,
• 10,000 paying customers.

With the recent survey indicating that the FreeRADIUS install base is close to 100,000 systems, we can immediately see why FreeRADIUS isn't going IPO any time soon. If MySQL can convert only 1/1000 of their install base to paying customers, we would expect FreeRADIUS to do about the same. That conversion rate would suggest that there are about 100 paying customers for FreeRADIUS, which fits in with what I've heard from companies doing support for FreeRADIUS.

With only 100 paying customers, it's nearly impossible to have a company, much less go IPO.

So I won't be getting rich off of FreeRADIUS, but I can at least take satisfaction in the knowledge that it's used by hundreds of millions of people every day to get on the net.

The IETF has spent a lot of time standardizing Diameter, which was supposed to be the next-generation successor to RADIUS. For a while, I was sure they were right. It turns out that Diameter doesn't matter as much as it could have.

For one, the Diameter base protocol is huge. The OpenDiameter people have been doing a good job of implementing it, but it's still much more complicated than RADIUS. That complexity has a cost: no one implements it.

Where a NAS vendor could spend a few days and have a pretty crufty (but working) RADIUS client implemented, the cost of implementing a Diameter client is much higher. As a result, almost no NAS vendors offer Diameter support. And since there's no support, there's no demand for it… which is a vicious circle.

The main benefits of Diameter are network features like guaranteed delivery, and automatic server discovery. Since the Radiator people cam up with RadSec, many of the benefits of Diameter can be obtained via RADIUS.

That effort hasn't (yet) translated into a RadSec implementation for FreeRADIUS, but it may happen soon. Once there are a few RADIUS implementations that usurp Diameter's functionality, there's even less reason to do a fork-lift upgrade to Diameter. In the end, I have a hard time seeing Diameter taking off anywhere, which makes it pretty much irrelevant for most people.