AAA and future Diameter support, questions

[Alan DeKok]

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 ^^)

  Pretty much.

> 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:
	http://freeradius.org/freeradius-client/

  3) a LGPL'd library, that's more complete:
	libfreeradius-radius.a

     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
best choice.


  Alan DeKok.