(RADIATOR) Secure reliable Radius? Now available for beta testing.

[Mike McCauley]

Hello again,

Thanks to all for the responses to this idea.

We now have a Radiator implementation available for beta testing.

The new protocol is called RadSec.

The beta code provides a TCP (or SCTP) connection between a Radiator <AuthBy 
RADSEC> client and a Radiator <ServerRADSEC> server. It allows any type of 
radius request to be proxied from the AuthBy RADSEC to the ServerRADSEC  and 
then handled as configured in the RadSec server. Replies will be carried back 
to the RadSec client and thence to the original requester. WE have tried to 
make it as much like AuthBy RADIUS as possible and sensible.

The beta copes with disconnections by trying to reconnect at intervals. It can 
handle IPV4 or IPV6 addresses. The server can listen on multiple 
BindAddresses. The server can accept connections from multiple clients.

The RadSec connection can optionally be encrypted with TLS and optionally 
requires mutual authentication of client and server using PKI certificates.

There are sample config files radsec-client.cfg which shows how to configure 
to proxy to radsec-server.cfg. If you have Net::SSLeay available, you can 
also enable UseTLS and use the Radiator sample certificates to encrypt the 
TLS traffic.

The beta code and example config files are now available in the Radiator 3.11 
patch set. It has been tested so far on Linux, Solaris, NetBSD, Windows XP 
and Server 2003 and with Perl 5.6 and 5.8, and on x86 and Sparc processors.

Beta testers are invited to test this code in a real-world environment and 
report issues and suggestions direct to me.

Hope some people find this useful.

On behalf of the development team:
Cheers.


On Monday 07 February 2005 22:21, Mike McCauley wrote:
> Hello again,
>
> We got a good response to this idea. It seems that many people were
> interested. We have nearly finished the code now: It provides TCP/IP
> stream-based proxying with optional TLS encryption and optional mutual TLS
> authentication for client and server ends of the TLS connection. So it
> provides many of the features of Diameter proxying without the overhead.
>
> Anyone interested in beta testing over the next few days?
> Pls respond direct to me.
>
> Cheers.
>
> On Wednesday 02 February 2005 16:36, Mike McCauley wrote:
> > Hi All,
> >
> > we are thinking here about a new idea for Radiator, and wondering if
> > anyone else finds it interesting and perhaps useful.
> >
> > We are thinking of a new AuthBy RELIABLERADIUS which would open a TCP
> > connection to a remote Radiator and send Radius packets over a TCP
> > transport instead of UDP. The remote Radiator would have a Server
> > RELIABLERADIUS to listen for such requests.
> >
> > Clearly, such a TCP connection could also be secured with SSL or TLS,
> > using client and/or server certificates to authenticate each end and
> > encrypt the Radius traffic too.
> >
> > The benefits of this would be:
> >
> > 1. No more lost packets
> > 2. High security encryption of Radius traffic
> > 3. mutual authentication of each end of the tcp transport.
> >
> > Obviously this provides some of the features that are part of Diameter,
> > and our forthcoming raDiameter product will include these too, but in the
> > meantime....
> >
> > anyone interested?

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.