AAA and future Diameter support, questions
aland at deployingradius.com
Thu Feb 5 02:53:36 EST 2009
Sebastien Decugis wrote:
> You are right about this, I am not sure yet how to exchange data between
> both processes. RADIUS sure looks an attractive choice, with the bonus
> that it would directly provide a RADIUS/Diameter gateway for this EAP
> application (well, only need to change UNIX socket for INET sockets ^^)
> I am concerned by the fact that we might be limited by RADIUS
> capabilities in that case. If at some point some extension is added to
> Diameter but not RADIUS, this implementation would be unable to follow.
It's RADIUS. If you need to butcher the protocol... go right ahead.
It's easy to define vendor-specific attributes with vendor-specific meaning.
> It also adds some work to encapsulate / decapsulate in RADIUS messages.
Any idiot can do that. I've done it a number of times, and even got
it right some of those times. :)
There are other options:
1) re-use the radius code in hostapd
2) BSD licensed freeradius client:
3) a LGPL'd library, that's more complete:
It's part of the main "freeradius-server" distribution, and isn't
broken out into a separate package.
I wouldn't suggest writing your own RADIUS implementation at this point.
> On the other hand, the "protocol" has to transport: EAP messages, key
> material, eventually some configuration options and error codes. It
> would not be very complex. Maybe just sending the data encapsulated in a
> TV or TLV is enough, and quite easy to implement and extend... Well, I
> am not decided yet. If I go for RADIUS use, would you help me for the
> decapsulation part? :)
It's better to re-use code than to re-write it.
If you want simple transport, the hostapd code is fine, but isn't
broken out into a separate RADIUS library. If you want a BSD licensed
library, freeradius-client is fine. If you want to support 1000's of
attributes and vendor-specific attributes, libfreeradius-radius is the
More information about the HostAP