Alan DeKok's RADIUS Blog

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.

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.

While the server is a great product, it fails on a number of accounts. Documentation is a popular choice, but I don't think that's the worst of its problems.

The worst problem is that it works.

Yes, I know a lot of people on the users list will disagree with me, especially the ones who are fighting with the previously mentioned lack of documentation. But given recent statistics, the few people every day who discuss their problems are about 0.1% of the install base. The rest of the users (for the most part) install it without major grinding of teeth, and then proceed to forget about it. They manage their users in an SQL or LDAP database, and don't really change the server configuration. Ever.

They don't change it because it just works. That's what software should do.

This means the project is a commercial failure, because it's difficult to sell costly support, upgrades, or other commercial value-adds when the customer is content with what they have. That's fine, because there are a good number of commercial RADIUS products based on FreeRADIUS. This means that even if you're paying for a RADIUS server, the odds are pretty good that if it's not IAS or ACS, it's a rebranded FreeRADIUS.

That's a successful commercial product.

I'm not done the book yet, so this blog may be a little premature. Still, I've learned a lot from what I've written so far. The main one is that the hardest part of the book is simply finding the time to write it.

The next hardest part is figuring out how to organize it. But I've solved that problem, I think. My solution is to concentrate on writing the contents first, even if that means the drafts look like a random collection of notes. As the notes get fleshed out into paragraphs, sections, and chapters, the organization grows naturally.

As of this writing, I'm up to 60 pages, and I have only about 5 pages that are specific to FreeRADIUS. Just explaining the concepts behind RADIUS, and correcting common misconceptions is taking a fair amount of space. That's good, though. It means that that the rest of the book is built on those foundations, and isn't just a jumble of “how-to's”.

The finished book will have a number of “how-to's”, of course. But without the additional background materials, they help people copy configurations, which is not the same as helping them to solve problems.