Scorpion Software Corporate Weblog

« Career Opportunity: A driven sales associate with a passion to help small businesses | Main | AuthAnvil v1.5 Released »

January 19, 2008

How have we made the VPN experience in AuthAnvil better?

There has been some scuttlebutt in the community about a few significant architectural changes in AuthAnvil v1.5. I thought it would be appropriate to talk about them ahead of the release to get you prepared for the upgrade.

The good news is that the changes have been welcomed, at least around here and with our partners who have had a chance to see it. We have made some significant strides to address some real problems exposed by our product in Microsoft's Internet Authentication Service (IAS), and its interaction with Microsoft Small Business Server 2003.

Since the original design of AuthAnvil, we always wanted to work within the Microsoft family of products. We felt it made more sense to leverage Microsoft's RADIUS implementation in IAS rather than write our own. It would save time in both development and testing, and would offer unparalleled implementation opportunities into the existing Microsoft infrastructure.

In v1, our solution was to take advantage of Microsoft's public API to extend their IAS product with a 3rd party extension to add strong authentication support. And it worked quite well. We have a number of customers leveraging RADIUS to provide AuthAnvil two-factor authentication for firewalls, VPN concentrators and even logon support for systems supporting PAM, including Linux and OSX workstations and servers. The problem was that this decision alienated our SBS 2003 Premium customers that are running Microsoft's Internet Security and Acceleration Server (ISA). Microsoft has a known, but undocumented, design flaw in which systems cannot have both ISA and IAS on the same server if you wish to provide 3rd party extensions and still offer VPN support. This meant that none of our SBS customers with ISA could use AuthAnvil without turning off VPN. Not a very practical solution. And Microsoft made it quite clear that they have no intensions of fixing the problem.

What was worse was that within Routing and Remote Access Server (RRAS) Microsoft decided to make design decisions that allowed for the RFC standard Password Authentication Protocol (PAP) to be used for authentication, but did NOT offer the ability to encrypt the actual payload for the VPN client. This meant that you could not use AuthAnvil with Microsoft's Connection Manager or PPTP client without exposing the data to undue risk. This simply wasn't acceptable to us, and we decided we better add support for Microsoft's Challenge Handshake Authentication Protocol (MSCHAP), which addresses this.

After analysis and research we decided MSCHAP simple would not do. Famed cryptanalyst Bruce Schneier has provided a well written and detailed paper on the fragility and weakness of PPTP due to MSCHAP from a protocol perspective. Agreeing with his conclusions, we decided to instead move to Microsoft's more recent work in MSCHAPv2, which overcomes these flaws and adds mutual authentication at the same time. This decision works rather well, as all recent Microsoft operating systems support MSCHAPv2; in Windows Vista MSCHAPv1 is not even supported.

We had originally added MSCHAPv2 support to our IAS extension in hopes to extend our existing product with the new payload encryption support. It was this decision that actually delayed AuthAnvil v1.5 from its original release date. We spent over three months working with Microsoft on various problems and difficulties that we found in this approach. It required an overhaul of the IAS extension, the DCOM Bridge, and AuthAnvil SAS that simply would not work well together. Last month we finally got the intercommunications all working correctly together and we thought we were close to release.

And then it went to testing.

We quickly found another major problem. When IAS is installed on a domain-joined system, it simply will not honour the mutual authentication hash we would provide as part of the strong authentication validation. It seems that the authenticator is built based on the user's domain password, and not able to be overridden by 3rd party extensions as expected. After intense discussion with Microsoft engineers over a period of some time it was found there may be a way to solve this, but that it would take some serious effort by both of our companies.

At that point it had been four months since we started tackling this problem. We were constantly coming across issues with the IAS API and were inadequately equipped in scope and ability to work around things. We had limited some of our client base, and quite frankly were constantly in a waiting mode working with Microsoft on solutions to problems we simply could not control. To top it off, if you have ever worked with IAS policy management, you know that it's extremely ugly when it comes to 3rd party extensions. You actually have to configure it in a way that ALLOWS packets through and HOPE that the extension handles it. If you get more than one extension installed, it is actually possible to expose IAS as an attack vector. We actually saw that on one client's network; a conflicting extension breached the security that AuthAnvil was providing. And this is not something we take lightly here.

If you know me at all, you know I thrive on complex challenges. They provide an opportunity to let us get out of our comfort zone and truly test our abilities and learn from our failures as we explore different solutions to overcome them. This was no exception. My team was constantly challenged with inadequacies in how IAS worked, and it was apparent we were relying too heavily on Microsoft to help us solve it. So I decided that we should take a different approach.

We threw out the IAS extension. That's right. IAS is gone. The very fact you can configure IAS in an insecure state and allow it to become an attack vector was unacceptable to me. As was the fact we could not rely on IAS to honour our RADIUS packet modifications to offer mutual authentication support. And eliminating the need for IAS immediately allowed us to have our clients with ISA back.

The result is the AuthAnvil Radius Server. It is a Windows service written purely in managed code, providing both PAP and MSCHAPv2 support and complete web service support to our AuthAnvil SAS. It natively installs and works on Windows Server 2003, Small Business Server 2003 and Windows Server 2008 and supports both 32bit and 64bit CPUs. It has an amazingly simple configuration wizard making it difficult to misconfigure, and impractical to break. Its support for MSCHAPv2 allows it to 'just work' with Microsoft's Connection Manager and offers strong authentication to any system supporting RFC compliant RADIUS clients. We have architected it to use 128bit RC4 encryption for the session keys, providing the highest level of encryption support available in standard PPTP clients. And it provides full mutual authentication between both the client and the server during its session.

We are very excited about this solution. It completely bypasses any reliance on Microsoft to fix their IAS server and allows us to focus on delivering strong authentication solutions to all of our customers. It has been a long few months, and we thank everyone for their positive support as we conquered these challenges. We hope you will enjoy the new update!

Posted by Dana Epp at January 19, 2008 06:15 PM

Trackback Pings

TrackBack URL for this entry:
http://www.scorpionsoft.com/blog/mt-tb.cgi/151

Comments

Post a comment